Server move in one day: what needs planning beforehand

On a project in early 2025, the actual server switchover took around 13 hours. That was possible because of the preparation in the weeks before. I describe how I planned the dependencies, the data migration and the time window for this server move, and which tasks were done before the day.

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.

The order on the day of the move

1. Last backupa full one, then no more write access
2. Remaining datato the new server
3. Line-of-business applicationstogether with the vendor where needed
4. Workstationsjoined to the new domain one by one, with user accountsMost of the time
5. Check at each workstationsign-in, drives, printers, applications
6. Final testapplications 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

Where that point lies, and which data state then applies, I agree with you beforehand. 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. In this project, 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 usually costs considerably 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?
• Is it agreed until when you can fall back to the old server, and which data state then applies?
• 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?

In my project in early 2025, the move itself, with a new domain and every workstation, was done in one day; I was on site for around 13 hours. How long it takes for you depends on the number of workstations, the applications and the volume of data. 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 switch back to the old server up to a point agreed in advance. Which data state then applies is settled beforehand.

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