Server and Workload Migration for Physical and Virtual Servers
Server and workload migration rehosts individual physical or virtual servers into cloud instances, grouped by the application they serve, with cutover and testing planned per workload. NTSPL replicates with agent-based block tools, fixes OS and dependency issues before cutover, and signs off each workload with scripted functional checks on AWS, Azure or Google Cloud.
Delivered on
In scope
Why Servers Move Best as Workload Groups
Not every migration is a data centre exit. Often it is 20-80 servers spread across a head office, branch rooms and a hosting provider: a physical payroll server bought in 2017, a Linux box running cron jobs nobody documented, a domain controller under a desk. Each is a workload with its own owner, downtime tolerance and quirks, such as a licence tied to a MAC address or an app that writes to a local D: drive path hard-coded in its config.
NTSPL plans by workload, not by server count. Each workload gets a one-page card: servers, ports, owners, licence bindings, data volume, allowed downtime and a test script. Agent-based replication handles physical and virtual sources alike, so mixed estates follow one method. Cutovers are booked to each workload's own quiet window, and the source stays intact until the owner signs the test sheet.
Signals for a Workload-Led Rehost
Signals you need Server & Workload Migration
- 20-150 servers sit across several sites or a hosting provider, with no single facility deadline.
- Physical servers older than five years carry business apps and have no spare parts contract.
- Each application has a different owner and downtime window, so a big-bang weekend is impossible.
- You need specific workloads in cloud first, such as file, AD or ERP, to support a new office or acquisition.
When to choose something else
- If the trigger is emptying a whole facility by a date, run Data Centre to Cloud Migration so contracts and racks are planned too.
- If the app must change its runtime or database engine during the move, see Application Replatforming or Database Migration.
Workload Cards, Replication and Sign-Off
Workload cards
One page per workload listing servers, ports, licence bindings, owner, data size, downtime window and test script.
OS and agent readiness
Kernel, OS version and disk layouts are checked against the replication tool's support matrix; conflicting backup or AV agents are noted.
Agent-based replication
Block-level replication from physical or virtual sources into a staging subnet, throttled per site link.
Test cutover
A non-disruptive test launch is run and the owner executes the test script before the real cutover.
Cutover and source hold
Final sync, DNS or IP switch, functional check, and source kept shut down for 7-14 days.
Agent-Based Rehost Pipeline for Mixed Estates
Workload-Card Rehost Pipeline for Physical and Virtual Servers
Workload cards drive agent installation and block replication into a staging subnet. Test launches are validated by owners before final cutover moves traffic and the source is held for rollback.
Select any component
Workload-Card Rehost Pipeline for Physical and Virtual Servers: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Rehost Services on AWS, Azure and Google Cloud
MGN handles physical and virtual Windows and Linux servers with the same agent, with launch templates per workload; Systems Manager runs post-launch scripts.
Azure Migrate treats physical servers and VMs from other providers through agent-based replication with a replication appliance on site.
Migrate to Virtual Machines supports VMware, AWS and Azure sources natively; physical servers usually go through image import or an intermediate VM.
Rehost Choices: Sizing, Licences, Domain Placement
Like-for-like or right-sized at launch
Launch at measured peak plus 20%, not at the on-prem specification. Physical servers are usually 10-25% utilised, so a 32-core box often lands on 4-8 vCPUs. Where you lack 30 days of performance data, launch one size up and reduce it after two weeks of hypercare metrics rather than guessing low.
Licences bound to hardware
Some industrial and accounting software binds to MAC address, hostname or a USB dongle. Fix MAC-bound licences by assigning a static network interface in cloud and asking the vendor to rehost the licence. Replace USB dongles with network licence servers before the move; do not plan a USB-over-IP bridge into production.
Domain controllers and identity
Do not replicate domain controllers. Build new DCs in cloud, promote them, let AD replicate, then demote on-prem DCs once nothing points to them. Place at least two DCs in different zones, check FSMO role placement, and update DHCP and DNS settings in branch offices before the last on-prem DC retires.
When to rebuild instead of rehost
Rebuild when the OS is out of support, the server runs only stateless web or batch code, or the image carries years of drift. Rebuilding a stateless app from a script takes a day or two and gives a clean, patchable image; rehosting it copies the drift. Rehost stateful, poorly documented servers.
Per-Workload Rehost Steps
Workload cards and support check
Cards completed with owners; unsupported servers marked for rebuild.
Agent rollout and initial sync
Agents installed site by site with bandwidth caps; initial replication completes.
Test launches and owner testing
Each workload test-launched and signed off against its script.
Booked cutovers
Workloads cut over in their own windows, two to six per week.
Source retirement
Sources wiped or reused after their hold period ends.
What you receive
Workload Cutover Quality Measures
| KPI | Typical target |
|---|---|
| Workloads passing test launch first time | Above 85% |
| Cutover downtime per workload | Within the window on the card |
| Post-cutover incidents in 14 days | Fewer than 1 per 5 workloads |
| Average vCPU reduction versus source | 40-60% for physical sources |
Rehost Pitfalls Hidden Inside Individual Servers
| Risk | How NTSPL prevents it |
|---|---|
| Hard-coded local paths or IPs break after cutover. | A config scan for IPs and drive paths runs during card creation, and test launches use the cloud IP plan. |
| A licence tied to MAC or hostname deactivates on first boot. | Licence register is completed before scheduling and vendors confirm rehost terms in writing. |
| Replication saturates a branch link during business hours. | Per-site throttles and night-time initial sync are set before agents start. |
Rehost servers as-is or rebuild them fresh in the cloud?
Rehost when the server is stateful, poorly documented or tied to vendor software you cannot reinstall easily; it is faster and lower risk. Rebuild when the server is stateless, runs an out-of-support OS, or you already have install scripts, because a rebuild gives you a clean, patchable image and removes years of drift. A practical split in mid-size estates is 70-80% rehost and 20-30% rebuild. Do not rebuild a server just because rebuilding feels cleaner if nobody can explain how it was configured in the first place.
Key facts: Server & Workload Migration
Server & Workload Migration in Practice
2 Server & Workload Migration scenarios, from IT staffing and contract workforce and Sugar and ethanol manufacturing, plus related platform case studies.
IT staffing firm moves 46 office servers to Google Cloud without a payroll slip
Sugar mill group rehosts cane procurement servers from four mills in the off-season
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Audit firm moves 22 Windows servers to Azure and serves 180 staff via Virtual Desktop
Server & Workload Migration: Frequently Asked Questions
Can physical servers be migrated, or only VMs?
Physical servers can be migrated. Agent-based tools on AWS and Azure replicate physical Windows and Linux servers at block level, and on Google Cloud they usually go through image import or a staging VM. We check each OS against the tool's support list first.
How much downtime does each server need?
Usually 15-60 minutes per workload: the time for a final sync, a DNS or IP switch and the owner's functional check. Large databases or apps with long shutdown routines take longer, and the window is recorded on each workload card.
What does server migration cost?
Services typically run INR 10,000-25,000 per server, depending on testing depth, weekend work and how many licences need vendor rehosting. Rebuilds cost more per server but are often cheaper over three years because they avoid carrying drift. Native rehost tools add little or no licence cost.
Where should migrated servers run for Indian compliance?
For most firms, AWS Mumbai or Hyderabad, Azure Central India or South India, or Google Cloud Mumbai or Delhi. For DPDP Act 2023 obligations, we record which servers hold personal data, and we enable logging with 180-day retention for CERT-In from launch.
Do we need to change IP addresses?
Usually yes, and that is fine for apps using DNS names. For apps with hard-coded IPs, we either change the config during cutover or move a whole subnet at once. We scan configs for IPs while building each workload card.
What happens to the old servers?
They stay powered off for 7-14 days as a rollback option. After the workload owner confirms in writing that nothing is missing, disks are wiped with certificates and the hardware is reused for test, sold, or sent for authorised e-waste disposal.
Scoping Server & Workload Migration?
Start with the question buyers ask first: “Rehost servers as-is or rebuild them fresh in the cloud?” NTSPL will answer it for your estate and give you a fixed-scope proposal.