Keep your websites reachable, your domains controlled and DNS changes accountable.

The organisation should retain documented control of its domain and the authorised registrant or equivalent rights-holder details where applicable. Registrar access, administrative contacts, renewal responsibility, expiry dates and recovery methods should not depend on one employee or an undocumented third party. MiCiS can administer or coordinate the domain within the agreed scope while keeping the ownership and access path visible.

Domain-transfer timing depends on the domain type, registry and registrar processes, account access, transfer locks or codes, authorised contacts, renewal state and any rejection or rework. DNS changes can be made quickly once control is verified, but the visible result also depends on the previous TTL values and caching by recursive resolvers, networks and devices. A final cutover window is therefore confirmed only after the current records and control path have been reviewed.

Yes, when the domain’s DNS zone also contains mail and verification records. MX, SPF, DKIM, DMARC, Autodiscover and other TXT, CNAME or SRV records may support Microsoft 365, another mail platform or third-party services. Replacing nameservers without recreating the complete required zone can interrupt mail or validation. MiCiS inventories and validates the relevant records before the delegation or hosted zone changes.

Hosting commonly covers the agreed server or platform service, supported runtime, storage, certificate and backup responsibilities, account access and service support. CMS core, themes, plugins or extensions, custom code, content, SEO, third-party licences, application security remediation and new development are separate responsibilities unless they are explicitly included. The proposal should document which party maintains each layer.

The documented scope should state whether website files, databases and relevant configuration are included; the backup frequency, retention and storage location; how alerts are reviewed; who may request a restore; and how restoration is validated. A successful backup job is not, by itself, proof that the complete website and its dependencies can be recovered. Restore testing and recovery expectations must be agreed for the service.

The method depends on the hosting platform, certificate authority, hostname coverage, validation method and whether a CDN, reverse proxy or other edge service terminates HTTPS. Certificates may be issued and renewed automatically or may require manual validation and installation. The scope should identify the hostnames covered, renewal responsibility and expiry visibility. A valid certificate encrypts the connection but does not by itself secure the website application or its accounts.

MiCiS can reduce migration risk through discovery, compatibility checks, staging, test URLs, a defined content or data-freeze point, pre-cutover DNS planning, certificate preparation, validation and a rollback path. The achievable interruption depends on the website architecture, data changes, database size, external services, DNS caching and the current and target platforms. Zero interruption should not be assumed unless the design and testing support it.

Where the related services are within the MiCiS scope, MiCiS can retain one technical context and trace or coordinate the issue across registration, delegation, DNS resolution, certificate, hosting, website and integration layers. Registries, registrars, certificate authorities, hosting vendors, website developers and other third parties may still retain their own service responsibilities and restoration processes. The support boundary and escalation path are documented for the engagement.