Migrate WordPress through 3 decisions: prove the replacement on staging, authorise the cutover and define the rollback route. Separate a hosting move from a URL change. Copying files is only part of the work: the database, customer journeys, domain routing and records created during the move also need a deliberate plan.
For a Zambian business, a migration brief should explain what is moving and what remains with its current service. Website hosting, domain registration and business email may be managed separately. Do not assume that moving one requires replacing all the others, or that a successful homepage load proves every dependent service survived.
What should be proven on staging before DNS changes?
Start with an inventory of the source: important pages, media, forms, customer accounts and any transaction-dependent functions. Record which system is authoritative for each kind of data. A brochure site and a site receiving orders have different continuity problems because the latter can keep acquiring records after a test copy is made.
Take a recoverable copy of both the database and relevant files. The WordPress migration guide calls for an off-site database backup before direct database editing. Extend your operational checklist to identify the corresponding file copy and the configuration needed to use it. The purpose is a coherent recovery set, not a collection of unrelated downloads.
Check the WordPress address settings carefully. WordPress distinguishes the Site Address that visitors use from the WordPress Address identifying where its core files reside. They may coincide, but they describe different things. Record the intended destination values and let the person implementing the move assess the correct method rather than improvising changes to make a staging screen load.
Where URLs change, handle stored data with suitable tooling. WordPress warns that broad database search-and-replace can damage serialised values because some structures retain string-length information. It documents WP-CLI search-replace as one option for avoiding that issue. This is a reason to choose an appropriate migration method, not to paste a generic replacement command into an unknown live database.
Keep staging separate from the public customer journey. Use test submissions and controlled delivery settings so a rehearsal does not accidentally contact customers or create real obligations. Record what was deliberately disabled and what must be enabled at cutover. A form that works only because an important integration was bypassed is not a completed functional test.
If the public URLs will change, create a source-to-destination map. Google’s site-move guidance describes mapping existing URLs to their new equivalents and redirecting from old to new. Map meaningful pages individually. Sending every old address to the homepage can conceal missing content and makes it harder for visitors to reach the information they expected.
Use this original cutover sheet as a shared decision record. The entries are evidence requirements, not promises of a disruption-free move.
| Decision area | Evidence before cutover | Evidence after cutover | Rollback question |
|---|---|---|---|
| Content copy | Important pages and media checked | Public pages show intended content | Is the old copy still coherent? |
| Database | Recoverable export and rehearsal result | New records reach the intended database | Which post-cutover records would need preserving? |
| URL changes | Old-to-new page map | Redirect destination and final page checked | Can routing return without losing the map? |
| Domain routing | Current and intended records recorded | Public hostname reaches intended service | Which exact records would be restored? |
| Email dependencies | Mail-related records and owner identified | Expected mail route remains intact | Was email changed at all? |
| Index controls | Staging restrictions listed | Intended public pages are indexable | Which restrictions must remain on staging? |
How do you control cutover and make rollback meaningful?
Choose a cutover owner and an explicit decision point. The person approving the switch should have the staging results, unresolved exceptions and recovery references in front of them. “The developer says it is ready” is not a substitute for knowing which customer tasks were exercised and which were not.
Record the current domain settings before any change, including records that belong to services outside the website. Agree the exact change with the person responsible for DNS. Do not replace an entire zone merely because a new web host supplies a short setup list. This is an operational safeguard against affecting unrelated mail and verification services, not a claim about a particular provider’s interface.
Control writes during the final transfer. Decide how enquiries, account changes and orders arriving around cutover will be handled. If a final copy is required, state when it is taken and how it differs from the earlier rehearsal. Avoid promising a move without interruption where the actual application and routing behaviour have not been tested.
A rollback must account for new data. Returning visitors to the old server may restore an earlier application state while leaving new enquiries or orders on the replacement server. The recovery note should explain how those records are identified and reconciled. If that cannot be done safely, label it an unresolved cutover dependency rather than pretending that changing DNS back solves everything.
Review search controls at launch. Google advises planning the removal of development noindex rules when the move starts. Check the intended public pages themselves, not only a global dashboard setting. Keep staging restrictions in place where staging should remain private, while ensuring the production pages do not inherit an accidental block.
For removed content, decide what the visitor should receive. Google’s URL-move documentation recommends appropriate missing or gone responses for content that is not carried over. A redirect is useful where there is a relevant replacement; it should not disguise an unrelated destination as the same answer. Retain the rationale in the page map so later editors understand the decision.
Monitor the old and new URLs after the switch, as Google’s guidance recommends. Include public page responses, redirects and the customer tasks from the staging inventory. Search reporting can help identify further problems, but submission or crawling is not proof of immediate indexing or stable rankings. Record observed behaviour without inventing a recovery timetable.
Keep the old environment available according to the agreed recovery plan until its role is resolved. Document any remaining access, data or routing responsibility so the migration does not end with an unexplained second copy. For related website context, see Spout’s WordPress page, or get started with a redacted cutover sheet and a clear description of what is moving.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.