Server move in one day: why the preparation takes longer than the move

A new server, a new domain and every workstation moved across, and the next morning staff simply carry on working. A server move like this fits into a single day, provided the day itself is nothing more than working through a plan. This article covers what has to happen beforehand, what a schedule looks like and where the time actually goes.

The starting point

The reason is usually the same: a server has reached the end of its life, the operating system no longer receives updates, and over the years shares, permissions and applications have grown without anyone keeping track. In the project in early 2025 that this article is based on, several line-of-business applications also ran on the old server and had to move with it.

The goal was a new virtualisation host with a freshly set up Active Directory, arranged so that by the end of the day every workstation was a member of the new domain and staff would find their data, drives, printers and programs as usual the next morning.

What happens before the day of the move

The real work happens weeks before the date. I split it into four areas:

The schedule

For the day of the move I write a plan with times. For each step it states when it starts, how long it may take and what comes next. Roughly, it follows this order:

1. A last full backup of the old server and a stop to all write access.
2. Transfer of the remaining data to the new server.
3. Moving the line-of-business applications, together with the vendor where needed.
4. Joining the workstations to the new domain, one by one, carrying over the user accounts.
5. A check at every workstation: sign-in, drives, printers, applications.
6. A final test of the applications with real data.

Between the steps there are decision points. If a step takes much longer than planned, the plan already says whether to carry on or roll back.

The fallback plan

The old server stays unchanged and ready to start until the new one demonstrably works. If an application does not start or data is missing, I can restore the previous state, and the next morning people work as before. With luck, a plan like this is never needed. Having it makes the day much calmer, though, because not every decision has to be made under time pressure.

The day itself

In this project I was on site for around 13 hours. Most of that went on the workstations: I joined each computer to the new domain, carried over the user accounts and then checked drives, printers and applications. It is not demanding work, but it adds up, and it can only be sped up so far.

The next morning I was back before the working day began. The first sign-ins show whether anything is missing, and I can answer small questions at the desk before they turn into a queue of tickets. Staff were able to work normally.

Where does the time really go on a server move?

Into planning. The concept, the inventory and agreeing things with vendors and staff take a lot of time. That time is worth taking. Every hour missing here costs many times more on the day of the move.

Into data transfer. Large volumes of data take longer than the calculation on paper suggests. That is especially true when part of the data moves to the cloud, to SharePoint for example. There, the speed depends on your own connection and just as much on the number and size of the files. It therefore pays to transfer large data sets before the day of the move, so that only changes follow on the day itself.

What I would do differently next time

Allow more buffer. The day worked, but it was long. Every step that takes a little longer than estimated pushes all the following ones back, and the end of the plan is where the tests are, which is exactly where you least want to rush. These days I build in a more generous buffer from the start and decide which steps can move to the next day if necessary without affecting operations.

Checklist for your server move

• Have all services, shares, printers and applications on the old server been recorded?
• Do the vendors of your line-of-business software know about the move, and is it clear what they need on the day?
• Is the new server fully set up and tested?
• Is there a schedule with times and agreed decision points?
• Will the old server stay ready to start until everything works?
• Have large volumes of data been transferred in advance?
• Do staff know what changes for them and whom they can ask the next morning?

Frequently asked questions

How long does a server move take?

The move itself, with a new domain and every workstation, fits into one day. In my project in early 2025 I was on site for around 13 hours. The real work happens in the weeks before: the inventory, the planning, and setting up and testing the new server.

Does the vendor of my line-of-business software need to be involved in a server move?

Usually yes, because line-of-business software rarely moves without its vendor. I agree with each vendor beforehand what they need: database, licence, paths and a time for reactivation. On the day I move the applications together with them where needed.

What happens if something goes wrong during a server move?

The old server stays unchanged and ready to start until the new one demonstrably works. If an application does not start or data is missing, I restore the previous state, and the next morning people work as before.

Sources

• Replacing domain controllers: Microsoft Learn – Upgrade domain controllers to a newer version of Windows Server
• Transferring operations master roles: Microsoft Learn – Transfer or seize Operation Master roles
• Speed of migrations to SharePoint and OneDrive: Microsoft Learn – Migration performance guide for SharePoint & OneDrive
• Virtualisation with Proxmox VE: Proxmox VE Administration Guide, Migrate to Proxmox VE