Moving systems between environments

An environment is the place where a system runs: servers, network, data storage and the settings without which the system will not start. Migration is moving a system from one environment to another together with its data, so that it works the same way on the other side. We move systems in three directions: from your own server room to the cloud, meaning servers rented from a provider over the internet; from one cloud to another; and from the cloud back to your own servers.

We start by listing what the system needs. We list the data and its size, the connections to other systems, and the schedules: jobs the system runs on its own at fixed times, such as nightly reports. We list the permissions, meaning who can get into the system and from where, the addresses at which users find it, and the passwords and keys to other systems.

We move the data with a comparison: after the move we count records, totals and dates in the old and new environments, and open selected documents in both. Then the old and new environments run in parallel for an agreed period: the new one receives a copy of current data, and a designated department works in it while the rest of the company uses the old one. Before the switchover we write a rollback plan: what signals that something has gone wrong, who makes the decision, and how we return to the old environment without losing data entered in the new one.

The move ends with the old environment shut down. We archive what the company is required to keep and delete the rest; you terminate the contract with the old provider, and from that day you pay for one environment. We follow the same route when a provider changes its terms and you want to leave it: the inventory shows which parts of the system rely on services available only from that provider, and we start with those. Designing the target cloud setup, meaning network, access and costs, is a separate scope. Preparing your own server room for a move back and securing the new environment are separate scopes too.

1. We list what the system needs. We review the servers and the system settings, and talk to the IT department and the users. Result: an inventory of dependencies and a list of changes needed in the new environment.
2. We do a trial move. We run the system in the new environment on a copy of the data, compare the data and let a selected department work in parallel with the old environment. Result: a comparison report and a list of differences to remove before the switchover.
3. We switch over with a rollback plan. At the agreed moment we direct users and other systems to the new environment, and the old one stands by. Result: the system runs in the new environment, and the rollback rules are written down.
4. We shut down the old environment. After the agreed period we archive what has to be kept, delete the rest and give you a list of contracts to terminate. Result: a shutdown report, one environment and one bill.

1. What is the full list of what our system depends on, and who checked it with the users?
2. How will you compare the data in the old and new environments, and who on our side will sign the comparison report?
3. How long will the old and new environments run in parallel, and what happens to data entered during that time?
4. What is the signal to return to the old environment, who decides on it, and what does the return look like?
5. Which of the new provider's services tie us to it in a way that will make the next move harder?
6. When will the old environment be shut down, what will be archived from it, and who will terminate the contracts?

How much of this applies to your system is shown by an analysis of the system and both environments: we start with it, and the result is a recommendation on whether to move, in what order and with what rollback plan.