Cloud Migration Plan: Inventory, Order, Test, Rollback
A cloud migration plan has four parts: an inventory, a moving order, a test environment and a way back. Here is what causes outages and how to avoid it.
rabbitclip teamPublished: 6 min read
Short answer
A cloud migration plan consists of taking an inventory of the current system, putting the parts in order according to what depends on what, testing each step without touching the live site, and leaving a route back to the old set-up in case something goes wrong. If a plan lacks these four steps, the move is not a migration but a gamble. The sign of a successful move is not speed; it is that users notice nothing at all.
Most migration trouble comes not from technical difficulty but from a forgotten piece: a scheduled task running on the old server, a mail rule, or a setting that only one person knew about. That is why the most valuable part of a plan is not the list of jobs to do but an honest account of what exists.
Where do you start: how is an inventory drawn up?
An inventory is a written list of everything that will be moved: sites, applications, databases, file storage, scheduled tasks, domain names, SSL certificates, email accounts and third-party connections. For each item you note who owns it, how critical it is and what it depends on.
The question that does the most work at this stage is what happens if this piece stops. If a booking form stops, revenue is lost; if an internal reporting tool stops, a report arrives a day late. That distinction decides the order of the move and the amount of downtime you can accept.
- Sites, applications and the databases they use.
- Scheduled tasks and scripts running in the background.
- Domain records, DNS settings and certificates.
- Email accounts and the forwarding attached to them.
- Third-party connections such as payments, maps and analytics.
In what order should the parts be moved?
The general rule is to move first what has few dependencies and little risk. A test environment or an internal tool suits a first attempt, because a mistake costs little and the team learns the process. Systems that touch customers directly come once the routine has settled.
Parts that depend on one another should be thought of together. If an application and its database run in different places, the delay between them can cause speed problems. That is why moving one system in a single step, with its related parts, is often the safer course.
How do you test without touching the live site?
A test environment is a copy built on the new infrastructure and not yet open to users. A current copy of the database is taken, the application is run in the new environment, and every important flow is tried by hand: sign-in, form submission, payment, email notification, file upload.
Next, behaviour under load is observed. If a flooring manufacturer's product catalogue gets heavy visits in the morning, that load should be simulated in the test environment too. Speed measurements make sense for comparison only if they are taken the same way before and after the move.
Finally, the hour of the switch is chosen. A move made in the quietest slice of traffic shrinks the effect of any hiccup. Because DNS changes take time to spread, lowering the TTL value before the move is a separate preparatory step.
- Build the new environment with a current copy of the data.
- Try sign-in, form, payment and email flows by hand.
- Simulate behaviour at a busy hour.
- Measure speed the same way before and after the move.
Why is the way back written first?
A rollback plan is the written account of which steps return you to the old set-up, and how long that takes, if something goes wrong during the move. It is prepared before the move, because calm thinking is hard once the problem has arrived. Keeping the old system running unchanged for a while after the move is the foundation of that plan.
An important decision for rollback is where data gets written. Orders or forms created on the new system after the move can be lost if you return to the old one. So how data will be kept in step during the migration window, or when writing will be frozen, is settled beforehand.
When is moving to the cloud the wrong choice?
If the system is small, traffic is steady and the current hosting works without trouble, a move often brings no gain. The effort of moving, the burden of managing the new set-up and the risk of error remain, while the return is uncertain. A move needs a reason: a capacity limit, a need for continuity, or an inadequate current provider.
Moving just before a heavy campaign or season is also bad timing. For a spa group, the weeks before the summer booking rush are a period when the team will have no time to fix problems. Placing the move in a quiet period matters as much as the plan.
What mistakes are common in a migration?
The commonest mistake is to skip the inventory and go straight to moving. A forgotten piece shows up days after the move, at a moment nobody expected. The second mistake is to test on the live site instead of in a test environment, which turns your users into the test team.
The third mistake is to shut down the old system right after the move. An old system that is not kept in parallel for a while removes the option of going back. The fourth is to leave the move in one person's knowledge; if the process is not written down, nobody can step in when that person is away.
- Starting to move without an inventory.
- Testing on the live site instead of a test environment.
- Shutting the old system down right after the move.
- Leaving the process in one person's memory.
A cloud migration plan begins with an inventory, is ordered by dependency, is tested in a separate environment and is made safe by a way back. When those four steps are skipped, the risk of an outage becomes greater than the move itself. If you would like to talk through whether your current system deserves the cloud and how the move should be planned, you are welcome to arrange a discovery conversation with rabbitclip.
FAQ
How long does a cloud migration take?
It depends on the size of the system, the number of dependencies and the scope of testing. A small site can move in a day or two; a system made of many linked parts can take weeks.
Will the site go down during the move?
In a well-planned move users notice no outage. The new environment is built and tested in advance, and the DNS change is made at a moment when traffic is low.
Is a rollback plan really necessary?
Yes. Calm decisions are hard once a problem has arrived. Keeping the old system running for a while and writing down the steps back stops a hiccup growing into a crisis.
Should I move everything at once?
Usually not. Starting with low-risk parts lets you learn the process and catch mistakes on a small scale. Parts that are tightly linked should, however, be moved together.
