In this guide 6 sections
A cloud migration checklist has five phases. Inventory every application and account, set security and recovery targets, rehearse on a copy of production, plan the cutover window, then monitor cost and data integrity for weeks. Skipping the rehearsal is the costliest shortcut. Each phase needs written exit criteria.
A full inventory, not just a list of servers
Migrations fail on undocumented things. Before choosing a provider or a date, list every application, database, integration, cron job and nightly export that touches the systems you plan to move. Small tools hide the worst surprises.
Account ownership gets skipped most. Ask who holds the domain registrar login, the SSL certificate, the payment gateway API keys and the old hosting provider’s admin account, because a former sysadmin often does. Settle this before migration weekend.
- Every application and its owning department.
- Every database, its size and change rate.
- Every payment, SMS, SMTP relay and accounting integration.
- Every credential and who can reset it.
Security, capacity and recovery targets
Decide these before anything else. Security targets cover who may access which data, whether it must be encrypted at rest, and whether a regulation or client contract restricts where it may be stored. Ask a qualified adviser about current rules.
Size capacity for your busiest hour of the last twelve months, because that figure is more reliable than any industry survey or vendor brochure. Recovery targets state how much data loss is acceptable and how quickly each system must return after a failure, and the two answers differ for every system. Those numbers should drive backup design.
Rehearse the migration before you trust it
Run the real process against a copy of production in a non-live environment, covering data transfer, configuration, application testing and a full login by every kind of user. Real volumes expose what small samples hide. Typical finds are a script that times out, a character-encoding mismatch, or an integration hard-coded to one IP address, none of which shows up in a ten-row sample.
Define “working” in writing first. List the transactions that must complete, the reports that must match the old system’s totals, and the users who must be able to log in. Define the rollback trigger too: the exact condition that means you stop and revert, so nobody has to decide under pressure at midnight on cutover night.
The cutover, the communication and who is on call
Pick the cutover window with the lowest real business impact, usually outside peak hours, and announce it to staff and affected customers well before the day. Say exactly what will not work during the window, such as checkout, invoice printing or the customer login, rather than warning of “some downtime.” Vague notices breed support calls.
Lower the DNS time-to-live a day beforehand, so the switch to the new address propagates within minutes and a rollback to the old one does the same. Name who does the work. Name who is on call afterwards. Tell staff how to report a problem in the first week, because a migration that works technically but leaves users unsure whom to call still feels like a failure.
Performance, cost and data integrity after the move
Week one matters less than month one. Compare application performance against the old environment, and confirm that scheduled jobs, reports and integrations still run as they did before the move. Silent failures surface weeks later.
Keep the old system a while. Keep it available, read-only, until one full month-end close has run on the new system and finance has confirmed that the reports match. Only then cancel the old hosting contract and archive its final backups on immutable storage somewhere you can still read them when an old transaction is questioned.
Check the bill daily. A resource left running at full size, or a data-transfer setting nobody checked, shows up quickly under usage-based billing, so a daily glance catches mistakes early. Fix it in week one.
Migration phase-gate checklist
A five-phase checklist covering inventory, requirements, rehearsal, cutover and post-migration monitoring, with written exit criteria for each phase, for example a signed account list. No phase starts unsigned. Deadlines then cannot squeeze out the rehearsal.
Open a blank worksheet to printQuestions owners ask
How can downtime be reduced?
Rehearse on a copy of production so the real cutover repeats a known process instead of a first attempt, and rehearse the rollback as well. Pick a genuinely quiet window. Keep the old system live as a fallback until the new one has proven itself, rather than decommissioning it on day one.
What should be checked before switching traffic?
Compare a sample of real customer, order and invoice records between the old and new systems, line by line, before any traffic moves. Retest every integration and scheduled job with a test payment, a test email and a sample report, because reconfiguring something is not proving it works. Then try the rollback itself.
Who should own the migration?
Appoint one accountable person on the business side, supported by whoever runs the technical work and by a named contact in each department that uses the systems. The technical lead knows what can be moved, but only a business owner can accept downtime, approve the cutover window and order a rollback. Name both before the inventory starts.