What to provide for a website migration

Service inventory

Tell us everything that must move or keep working

• Websites and hostnames: root domain, www, subdomains, aliases and redirects.
• Application: CMS/framework, version, PHP requirements, document root and licensed components.
• Data: database names, engines, sizes and which application uses each one.
• Email: provider, mailboxes, aliases, forwarding and approximate message volume.
• DNS: nameservers, zone provider and who can approve or make the final change.
• Integrations: payments, APIs, scheduled jobs, webhooks, SMTP, storage, analytics and IP allowlists.

Access required

Provide the highest-level access available

A hosting control-panel or server account is usually more complete than FTP alone because it exposes databases, scheduled tasks, configuration and mail. Depending on the source, UKC may need:

• Hosting control-panel or migration-tool access.
• SFTP/SSH or FTP access to all website files.
• Database access or a current database export.
• CMS administrator access for application checks.
• DNS or registrar coordination for the final switch.
• Access to external services only when configuration must be changed there.

Application details

Explain behaviour that a visual test cannot reveal

List administrator URLs, important forms and workflows, login areas, payment paths, cron jobs, background queues, custom rewrite rules and any non-public pages that must be tested. Supply valid test accounts without using a real customer's credentials.

Tell us about known errors, unsupported PHP code or existing outages so they are not mistaken for migration regressions.

Changing data

Identify what can change during copying

Orders, bookings, registrations, uploads, forum posts and mailbox messages may continue changing after the first copy. State how frequently this happens and when the site is quietest. UKC can then plan a final sync or short maintenance window without losing new data.

DNS and email

Preserve services that are not moving

Provide or export the full current DNS zone, not only the website A record. Highlight MX, SPF, DKIM, DMARC, verification and third-party service records. Say explicitly when email or another service must remain with its existing provider.

If DNS access is held by another person, arrange their availability for the agreed cutover.

Timing and approval

Define when the site can switch

1. Give the preferred migration and launch dates, timezone and busy periods to avoid.
2. Name the person authorised to approve the tested copy and final switch.
3. Agree whether maintenance mode is acceptable and for how long.
4. Keep the old hosting active until DNS transition and acceptance checks are complete.
5. Confirm who will test business-specific functions after cutover.

Before submitting

Use this concise request checklist

• Domain and complete hostname list.
• Current host and control-panel type.
• Application, database, PHP and storage details.
• Email and DNS ownership.
• Changing data and important workflows.
• External integrations and allowlists.
• Preferred dates, timezone and authorised approver.
• Secure access method agreed with UKC.

Start the migration

Send the inventory before the credentials

Open a migration ticket with the non-secret checklist first. Support can confirm the required access and secure handover method after reviewing the source platform.