A plant cannot simply switch off its servers for a weekend and hope for the best. The ERP drives purchasing and scheduling, the file shares hold drawings and work instructions, Active Directory controls who can log in to everything, and label printers and scanners on the shop floor quietly depend on all of it. This Windows server migration checklist for manufacturing plants walks through the work in the order it should happen, from inventory to post-cutover validation, so production keeps running while the infrastructure changes underneath it.
The checklist applies whether you are moving to new on-premises hardware, to a hosted private server or to a public cloud. If you want a team to run the move with you, our server migration service covers Linux and Windows workloads with a written plan and a tested rollback.
Why plant migrations are different from office migrations
An office can tolerate a slow Monday morning. A plant that loses its ERP connection mid-shift may stop receiving work orders, stop printing traveller sheets or stop booking finished goods. Several things make manufacturing unusual.
- Fixed production calendars: shifts, maintenance shutdowns and customer delivery dates define when downtime is acceptable, not IT preference.
- Old but critical software: ERP and MES versions often run on operating systems that are long past their prime, with vendor support tied to specific versions.
- Hard-coded connections: machines, scanners and label systems frequently point at a server name or IP address that nobody documented.
- Licensing tied to hardware: some industrial and engineering applications bind their licence to a machine identifier or a licence server.
- Low tolerance for surprises: a failed cutover is measured in scrapped batches and missed shipments, not just irritated users.
Phase 1: Build the inventory before you touch anything
Most migration problems trace back to something nobody knew was running. Start with a complete list of what exists.
- Every physical and virtual Windows server, with operating system version, role and owner.
- Every application on each server, including version, vendor and support status.
- Scheduled tasks, services running under named accounts, and any scripts that run overnight.
- Shared folders, their permissions and which departments or machines use them.
- Licences: operating system, database, ERP, CAD and any licence servers, with renewal and transfer terms.
- Certificates, service accounts and stored credentials that will need to move or be reissued.
Walk the shop floor as well as the server room. Ask supervisors which screens, scanners and printers they rely on, because those users will notice a failure before IT does.
Phase 2: Map dependencies across ERP, MES, printers and labels
A server is rarely a single thing. It is a node that other systems lean on. For each in-scope server, record what connects to it and how.
ERP and database
Identify the application tier, the database server, any reporting server and every integration that reads or writes data. Note the database engine and edition, linked servers, and whether the vendor supports the target operating system. Confirm with the ERP vendor that your version is supported in the new environment before you commit to a date.
MES, SCADA and shop-floor integrations
List every machine, PLC gateway, OPC server or data collector that talks to a server. Record the protocol, the address or hostname it uses and who maintains it. Some of these devices cannot be reconfigured easily, which means the new server may need to take over the old name and address.
Printers, label systems and scanners
Barcode and label software often uses specific drivers, shared printer queues and direct IP connections. Test each label template on the target environment. A shipping label that prints slightly misaligned can stop a dock just as effectively as a server outage.
Identity and file services
Active Directory, DNS, DHCP and Group Policy sit under everything else. Decide whether you are migrating domain controllers, adding new ones and retiring old ones, or moving identity to a hosted service. File shares need their permissions, mapped drives and any DFS namespaces preserved so users find their data where they expect it.
Phase 3: Choose the target and the method
Match each workload to the approach that fits its risk. Not everything has to move the same way.
| Workload | Common approach | Main risk to check | Typical downtime sensitivity |
|---|---|---|---|
| ERP application and database | Rebuild on new server, restore database, test thoroughly, cut over in a planned window | Vendor support for new OS and database version; integrations | Very high |
| Active Directory and DNS | Add new domain controllers, transfer roles, retire old ones | Replication health; hard-coded DNS references | High, as everything depends on it |
| File shares | Staged copy with a final delta sync at cutover | Permissions, open files, long paths | Medium |
| Print and label servers | Rebuild queues, retest every template and device | Drivers, direct IP printing | High on the shop floor |
| MES and data collection | Rebuild or lift and shift with identical name and address | Machine connections that cannot be reconfigured | Very high during production |
| Licence servers | Transfer licence with vendor, test before cutover | Hardware-bound licences | Medium to high |
| Legacy applications | Virtualise as is, or isolate, and plan replacement separately | Unsupported operating system; security exposure | Depends on the process it supports |
Where an application only runs on an unsupported operating system, do not let the migration quietly extend its life without a plan. Isolate it on its own network segment and record a decision about its eventual replacement.
Phase 4: Plan the downtime window around production
Agree the window with operations, not just with IT. Look at the shift pattern, planned maintenance shutdowns, customer shipment deadlines and month-end or stock-take periods. A planned plant shutdown or a quiet weekend is usually the safest slot, but confirm it with the plant manager and with anyone who runs overnight jobs.
- Write a minute-by-minute runbook that names who does each step.
- Decide in advance what operations will do on paper or offline if systems are unavailable longer than planned.
- Set a go or no-go checkpoint partway through the window, with a clear time after which you roll back.
- Tell shift supervisors, purchasing, shipping and quality in writing when the window starts and ends.
Phase 5: Backup and rollback, proven rather than assumed
A backup that has never been restored is only a hope. Before the window, take full backups of every in-scope server and database, store at least one copy away from the production network, and perform a trial restore to confirm the data is usable.
- Keep the old servers intact and powered off, not wiped, until the new environment has run through a full production cycle.
- Document exactly how to point users, machines and printers back at the old systems.
- Record the data cut-off point, so you know what must be re-entered if you roll back after new transactions were booked.
- Take snapshots of virtual machines immediately before changes.
The manufacturing server migration checklist
Use this list as a working checklist. Tick items off in order and assign a name to each one.
Before the project
- Full server, application and licence inventory completed and reviewed.
- Dependency map drawn for ERP, MES, printers, labels, scanners and file shares.
- ERP, MES and engineering software vendors confirm support for the target environment.
- Licence transfer terms confirmed for every licensed product.
- Stakeholders in operations, quality, shipping and finance briefed.
Preparation
- Target environment built, patched and secured.
- Test copy of the ERP and databases restored and checked by key users.
- Label templates, printer queues and scanner connections tested on the new servers.
- Backups verified with a trial restore.
- Runbook written, reviewed and rehearsed at least once.
Cutover
- Final backup and snapshots taken.
- Users logged off and scheduled jobs paused.
- Final data sync completed and checked.
- DNS, names, addresses and mapped drives switched as planned.
- Go or no-go decision recorded at the agreed checkpoint.
After cutover
- ERP transactions tested end to end: create an order, issue material, receive goods, print a label, book a shipment.
- Shop-floor devices confirmed against the new servers.
- Active Directory replication, DNS and Group Policy confirmed healthy.
- Backup jobs, monitoring and alerting reconfigured on the new servers.
- Old servers retained until a full production cycle and month-end close have completed without issue.
Post-migration validation that goes beyond "it starts"
A server that boots is not a migration that worked. Have people from each department run through their normal day on the new environment. Planners should confirm that schedules and material requirements look right. Shipping should print real documents. Quality should open drawings and record an inspection. Finance should confirm that postings reach the ledger. Keep a short issue log for the first two weeks, and review performance when the plant is under normal load, not only when it is quiet.
Also close the loop on security and housekeeping: remove old accounts and firewall rules, update asset records, confirm patching and update the disaster recovery plan to describe the new setup. If you want an outside team to own that validation, our Windows and Linux server migration team includes it in the scope as a written deliverable.
What drives the cost of a plant migration
We do not quote figures in articles, because the right number depends on your estate. These are the factors that move the price up or down.
- The number of servers and the complexity of the ERP and database layer.
- How many shop-floor devices and integrations need retesting.
- Whether you are changing hardware, hypervisor, operating system version or all three.
- The length and shape of the downtime window, and whether work must happen out of hours.
- Licensing changes triggered by the new platform.
- Rehearsal depth, rollback preparation and post-cutover support.
Ask every provider for an itemised quote that separates assessment, build, data migration, cutover and aftercare, so you can compare like with like.
Why Companies Choose CloudHouse for Server Migration
Clients choose CloudHouse because we plan delivery in clear stages, test the rollback before we need it and stay available for support after the cutover. Our quotes are transparent and itemised, so you can see what each phase costs and decide where to spend. You can read how we scope this work on our server migration company page.
Conclusion
A successful plant migration depends less on clever technology than on preparation: a complete inventory, an honest dependency map, a downtime window agreed with operations and a rollback you have already proven. Work through the checklist in order, validate with real users and keep the old servers until production has run cleanly. To discuss your environment and receive an itemised proposal, visit our server migration services page and request a quote.
