PLAN THE PERIOD Save 28% on 6 months · 50% on 12 months · paid upfront.
Migration & launch

Plan a client migration around the last write.

A client migration is ready when you can explain which system owns the current data, prove the destination works and stop safely if a critical check fails. Start with a written inventory and a rehearsal. Choose the change window only after the agency and client have agreed who approves the move, what must keep working and how new submissions will be protected.

Inventory the project before booking the move

Use an illustrative enquiry website at client.example.com: editors publish project pages, visitors upload a brief, and a scheduled task exports enquiries to a client system. Moving its public pages would cover only part of the job. Confirm authorized access to the source and destination, domain controls and recovery copies before committing to a date.

For every component, record its owner, version, location, dependencies and acceptance check. Keep credential locations in the inventory; keep passwords and private keys in the approved secret store.

Scroll horizontally for all table columns.

A starting inventory for the illustrative enquiry website
ComponentRecord before movingWho confirms it
Domain and DNSRegistrar, DNS operator, current records and TTLsClient account owner
ApplicationRelease, runtime, extensions and deployment methodAgency maintainer
Data and uploadsDatabase, upload paths, backup method and last usable copyData operator
Forms and integrationsRecipients, webhook endpoints and permitted test destinationClient workflow owner
Scheduled workCron or scheduler, time zone, queue and last successful runAgency maintainer

Prove the recovery copy before touching production

Restore into a separate test destination, never over the live database. For PostgreSQL, a SQL dump represents a consistent database snapshot, but a single-database dump does not include cluster-wide roles or tablespaces. Record the supporting objects required by your application. That database snapshot also does not make separately copied uploads consistent automatically. PostgreSQL SQL dump documentation.

For a WordPress project, include its files and database. If URLs will change, follow its migration-specific guidance: an indiscriminate database search-and-replace can damage serialized values. Rehearse the chosen method on the copy. WordPress migration handbook.

Record a known enquiry and its attachment, restore them, and verify both through the application. Keep the original backup protected outside the server being moved. A completed file transfer is not acceptance of the restore.

Rehearse the workflows the client will notice

Test using an access-controlled temporary hostname or an operator-only name mapping. Configure the application for that test route, including HTTPS and relevant callback URLs. Prevent the copy from sending production messages, processing real payments or running production schedules. Use approved synthetic records rather than unnecessary personal data.

Write an expected result before each check. Record pass or fail, evidence location and the person who reviewed it; a screenshot of the homepage cannot stand in for the whole grid.

Scroll horizontally for all table columns.

Rehearsal acceptance grid
WorkflowExpected resultEvidence to retain
Form and attachmentOne stored enquiry and one readable file; test recipient onlySynthetic record identifier and delivery observation
WebhookApproved test event reaches the intended test consumerEvent identifier and consumer result
Scheduled exportOne controlled run, correct time zone, no old-server duplicateRun identifier and exported record comparison
Editor and visitor routesExpected permissions, redirects, assets and HTTPS behaviorChecked URLs and any failure details

Define the last write on the old system

For this example, the agency proposes a brief maintenance window: pause enquiry submission and editing, stop the old export schedule, finish or account for queued work, then create the final database and upload copy. The client must approve how visitors are told that submissions are temporarily unavailable.

Record the last accepted enquiry identifier and the time writes stopped. Validate that the destination includes that record and its attachment before allowing new submissions. Keep the source unable to accept independent writes while DNS answers may differ. A project that cannot pause writes needs an application-specific synchronization design; do not improvise one during cutover.

Keep a DNS decision log

TTL controls how long DNS answers are cached. Lowering it at cutover does not invalidate answers already cached under the earlier value, so prepare any TTL change in advance and observe the transition from relevant networks. Cloudflare also notes that local caching can delay a visible change. Cloudflare DNS TTL documentation.

Log the record name and type, old value, intended value, previous TTL, approval, change time and observed result. Check IPv6 records as well as IPv4 records if both exist. Preserve unrelated mail records. After the change, verify the public hostname reaches the intended application and its critical workflow, not merely the intended IP address.

Make rollback a data decision

Agree concrete stop conditions: the final enquiry is missing, attachments cannot be opened, sign-in fails, or a webhook reaches the wrong recipient. Before new writes begin, a rehearsed return to the retained source may be possible. After the destination accepts new enquiries, restoring an old backup or reversing DNS alone can lose those records.

If a stop condition appears after reopening, pause writes, preserve both copies and have the named operator reconcile the changes before choosing the authoritative system. The client approver decides whether to continue recovery or use the agreed alternative. Keep a short incident log instead of repeatedly switching DNS.

Close the move with evidence and ownership

Have the client review the acceptance grid. Confirm one active scheduler, the new backup path, alert ownership and the next observation checkpoint. Retain the source for the agreed period, then approve its retirement explicitly. Remove temporary access and test data according to the project agreement.

Use the result to update the operating responsibility sheet and project budget. This procedure organizes your team's work; it does not imply included migration assistance or uninterrupted service.

Sources & review

Technical references were checked on September 12, 2026. Examples are planning exercises; referenced software documentation does not establish PrivateHostLab service capabilities.

A GOOD PLACE TO START

Make room for your next project.

Find your starting point