A migration can sound deceptively simple: copy the website, point the domain somewhere else and confirm that the homepage opens. That description leaves out the things a business may depend on every day. Customer records, uploaded documents, scheduled jobs, email delivery, payment callbacks and administrative permissions can live in different places.
Before discussing the move itself, make a short inventory of what the platform does and where each responsibility lives. This gives both the business and the technical team a shared picture of what needs to remain available.
What must still work on Monday morning?
Choose a small set of essential tasks. For a logistics business, that might include tracking a shipment and updating its status. For a service business, it could be receiving an enquiry and responding with the right context. For a commerce platform, follow an order through payment, administration and customer confirmation.
Write down the expected result for each task before moving anything. A familiar-looking screen is weak evidence if the records behind it are missing or the email never reaches its destination. Include a person responsible for confirming the business result, not only the person moving the files.
Understand what changes during the move.
Will users continue adding records while data is copied? If so, how will the final changes be included? Is a short maintenance window acceptable? Which systems will still send requests to the old address? These questions determine the cutover plan: the controlled point at which the new environment becomes the one people use.
If page addresses change, search visibility needs a separate workstream. Google’s site-move guidance recommends preparing the destination, mapping old URLs to new ones, applying redirects and monitoring the move. It also distinguishes URL changes from infrastructure-only changes. Use the guidance that matches the actual project rather than treating every migration as identical.
Write down the rollback decision.
A rollback plan should explain when the team would stop, who can make that decision and how the previous working service would be restored. It also needs to account for records created after the move. Simply switching the domain back can create a second problem if the two environments now contain different information.
Backups are part of that preparation. Ask what is included, where the copies are held and whether restoration has been checked. A folder labelled “backup” does not answer those questions. The recovery procedure should be understandable to whoever may need to use it under pressure.
After the switch
After the visible switch, review the important journeys again. Check incoming requests, scheduled activity, access and error reports. Keep a written record of what passed, what remains uncertain and when the previous environment can safely be retired.
The handover should name the checks that passed and leave a short list of anything still being watched. It should also say who can retire the old environment, and when. Until those decisions are made, avoid deleting the previous copy simply because the new homepage looks right.
Read further
Original sources behind the technical guidance in this article.