A server migration happens to a company rarely, so it is easy to treat it as an ordinary technical task. Yet it is a project in which an oversight can stop the whole company’s work for many hours. The good news is that downtime can be reduced to a minimum if you approach the topic methodically. The key lies in the preparation, not in the night of the switchover itself.

Reasons companies migrate servers

It is worth starting with the question of why we are doing the migration, because that affects the whole plan. The most common reasons are:

  • the end of support for the operating system or hardware,
  • moving from physical servers to virtualisation,
  • moving systems to the cloud or to a new server room,
  • consolidating several old machines into one modern environment,
  • rising maintenance costs of ageing hardware.

The goal sets the scope. Migrating a single application is a different project from moving an entire server room.

Step one, a thorough inventory

You cannot safely move something you do not know. Before you touch anything, gather a full picture of the environment:

  1. a list of servers, roles and running services,
  2. applications together with their dependencies, for example databases and directory services,
  3. network dependencies, addressing, firewall rules and DNS entries,
  4. accounts, licences and certificates tied to the systems,
  5. the time windows in which the systems are least loaded.

This is the most commonly skipped stage and, at the same time, the one where the most migrations come undone. An application that will not come up after the move is usually waiting for a service nobody remembered.

Step two, choosing the migration method

The method depends on what you are migrating and how much downtime you can accept.

  • Migrating a physical machine to a virtual one lets you move the whole server as an image.
  • A clean install and moving the data gives a cleaner environment, but requires more work.
  • Replicating data in the background before the switchover shortens the downtime window almost to a minimum.

For critical systems it is worth choosing an approach that lets you prepare the new environment in parallel and switch traffic over only after testing.

The calmest migrations are the ones where nothing new happens on the night of the switchover. All the work is done earlier, the new environment waits ready, and we just switch the traffic over and check the checklist. If you are improvising on the migration weekend, it means the preparation was too weak.

Step three, the downtime and rollback plan

Two documents save your skin on migration day.

The maintenance window plan describes:

  • the exact order of actions and the people responsible for them,
  • the moment when the systems are unavailable to users,
  • the criteria for considering the migration successful.

The rollback plan answers the question of what to do if something goes wrong. It should contain a clear point of no return and a way to quickly restore the previous state. A migration without a rollback plan is a gamble.

Step four, backup and tests before the switchover

Before you touch production, make a full backup and check that data can be restored from it. It is your safety net.

Then test the new environment before the switchover:

  • launch the applications and check user sign-in,
  • verify access to databases and network resources,
  • check printing, integrations and connections to external systems,
  • confirm that the backup of the new environment works.

Step five, communication with people

Technology is half the success, the other half is people. Inform the team in advance about the maintenance window, the expected unavailability and where to report problems after the migration. Designate a first point of contact for the day after the switchover, because that is exactly when small glitches surface.

The most common migration traps

A few mistakes repeat in almost every failed migration I hear about:

  • overlooking dependencies between systems, so an application does not come up after the move,
  • no real backup test before the switchover, that is a false sense of security,
  • a maintenance window that is too narrow and leaves no time to react when something goes wrong,
  • a migration with no rollback plan and no designated point of no return,
  • no information for the team, so the support desk drowns in requests the next day.

Each of these can be eliminated at the preparation stage. That is why a good migration looks boring and predictable from the outside.

The checklist in brief

  1. Inventory the environment and dependencies.
  2. Choose a migration method matched to the acceptable downtime.
  3. Prepare the new environment in parallel with production.
  4. Make and check a backup before the switchover.
  5. Describe the maintenance window plan and the rollback plan.
  6. Test everything before switching traffic over.
  7. Inform the team and provide support after the migration.

A migration carried out methodically can be surprisingly boring, and that is exactly the point. If you are planning to move systems and want to do it without long downtime, see how we deliver server migrations and ongoing server administration. I will help you plan the maintenance window and prepare a rollback plan before we touch anything in production.