India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Migration Factory and Wave Planning for 150 to 1,500 Servers
A migration factory is the operating model for moving hundreds of servers on a fixed cadence: standard intake, wave planning, squads with defined roles, reusable runbooks and a weekly throughput target. NTSPL sets up the factory, runs waves of 20-80 servers every one or two weeks, and tracks throughput, rollbacks and blockers until the estate is moved.
Delivered on
In scope
Why Large Migrations Stall Without a Production Line
Large migrations rarely fail on technology. They fail on throughput: three months in, 40 servers have moved out of 600 because every wave is planned from scratch, app owners are chased one by one, and the same firewall request is raised six times. At that rate the programme takes four years, double running eats the savings and the business case collapses. Most stalled programmes we see have good tools and no production line.
NTSPL builds the factory before scaling the waves. Each workload passes an intake gate with owner, test script, window and dependencies before it can be scheduled. Waves follow a fixed calendar, squads have named roles from wave lead to tester, and runbooks are templates filled per wave. A weekly control meeting reviews throughput against target and clears blockers, and the plan is re-cut every month on real velocity.
Estates Big Enough to Need a Factory
Signals you need Migration Factory & Waves
- 150 or more servers or 40 or more applications must move within 6-18 months.
- A programme is running but has moved less than 20% of the plan after a quarter.
- Several business units, vendors or sites need one coordinated calendar.
- Leadership wants a weekly number showing whether the end date is still credible.
When to choose something else
- Under 80 servers, the overhead of squads and gates outweighs the gain; a single migration team with workload cards is enough.
- If the target landing zone is not built, build it first; a factory feeding an unfinished platform queues every wave.
Intake, Wave Calendar, Squads and Control
Intake gate
Workload readiness checklist: owner, test script, window, dependencies, licences and firewall rules.
Wave calendar
Fixed cadence with freeze periods, dependency groups and a three-wave look-ahead.
Squad model
Wave lead, migration engineers, network and DBA support, app tester and change manager per squad.
Runbook templates
Standard runbooks per pattern, such as rehost, database and file, filled per wave.
Control tower reporting
Weekly dashboard of throughput, rollbacks, blockers and forecast end date.
Intake-to-Wave Factory Flow
Intake-to-Wave Migration Factory Flow
Workloads enter a backlog, pass an intake gate and are assigned to waves on a fixed calendar. Squads execute from templates, and every wave feeds metrics to a control tower that re-forecasts the end date.
Select any component
Intake-to-Wave Migration Factory Flow: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Factory Tooling and Tracking on Each Cloud
MGN supports grouping servers into applications and waves, and its post-launch actions automate standard steps such as agent installs.
Azure Migrate groups and dependency views help form waves, and replication can be started in batches per wave.
Migrate to Virtual Machines uses groups and can run test clones before cutover, which fits a midweek test, weekend cutover cadence.
Factory Design Choices: Wave Size, Cadence, Squads
Wave size and cadence
Start with pilot waves of 10-15 servers, then scale to 30-60 per squad per fortnight. A squad of six to eight people can usually sustain 25-40 servers a week of standard rehost work. Do not increase wave size until rollback rate stays under 5% for three waves. Weekly waves suit estates over 500 servers; fortnightly suits most mid-size programmes.
How waves are formed
Group by dependency first, then by business unit and window. Keep tightly coupled app and database servers in one wave. Fill remaining capacity with independent workloads that passed intake. Avoid waves that span more than three app owners; coordination cost rises faster than wave size. Shared infrastructure, such as file servers, gets its own wave.
Squad structure
Each squad has a wave lead, two to four migration engineers, shared network and DBA support, and an app tester from the business. One change manager can cover two squads. Add a second squad only when intake can feed it, otherwise squads wait. For partner-led factories, keep the wave lead role inside the client or with one accountable partner.
When to re-plan
Re-cut the plan monthly using measured velocity, not planned velocity. If actual throughput is under 70% of plan for two months, act on the bottleneck: usually intake readiness, app tester availability or firewall lead time. Adding engineers rarely helps when the bottleneck is upstream. Publish the re-cut plan to every app owner.
Factory Ramp-Up from Pilot to Full Velocity
Backlog, intake gate and calendar
Workloads loaded, readiness checklist agreed, freeze dates set.
Squad setup and templates
Roles filled, runbook templates and reporting built.
Pilot waves
Two or three small waves to tune templates and timing.
Ramp to target velocity
Wave size and squad count increased as rollback rate allows.
Sustained waves and tail
Steady waves, monthly re-plan, and a tail plan for hard workloads.
What you receive
Factory Throughput and Quality Measures
| KPI | Typical target |
|---|---|
| Servers migrated per week | 25-40 per squad at full velocity |
| Wave rollback rate | Under 5% |
| Workloads waiting at intake over 4 weeks | Under 10% of backlog |
| Forecast end date drift | Under 2 weeks per month |
| Source servers decommissioned within 30 days of migration | Above 90% |
Factory Bottlenecks and How to Clear Them
| Risk | How NTSPL prevents it |
|---|---|
| App owners are not ready and waves run half-empty. | Intake gate fills waves only from ready workloads, and owner readiness is reported by business unit to the steering group. |
| The last 15% of hard workloads stalls the programme. | A separate tail plan starts by month three, with dedicated specialists for those workloads. |
| Migrated servers stay running on-prem and costs double. | Decommissioning is part of done; a wave is not closed until sources are shut down. |
Migration factory or project-by-project migration?
Use a factory when you have more than about 150 servers or 40 applications and a target date within 18 months. The upfront effort of intake gates, templates and squads, usually three to four weeks, pays back once waves run on cadence, cutting per-server effort by 30-50%. Use project-by-project migration for smaller estates or when applications are so different that templates cannot be reused, such as a few large ERP and mainframe moves. Many programmes combine both: a factory for standard rehost workloads, and separate projects for the five or six complex systems.
Key facts: Migration Factory & Waves
Migration Factory & Waves in Practice
2 Migration Factory & Waves scenarios, from Glass manufacturing and Polymer and specialty plastics manufacturing, plus related platform case studies.
Glass manufacturer restarts a stalled programme and moves 410 servers in 22 weeks
Polymer company runs one wave calendar for three plants and a head office
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
EPC company vacates its owned data centre in 7 months and halves run cost
Migration Factory & Waves: Frequently Asked Questions
How many servers per week can a migration factory move?
A trained squad of six to eight people typically moves 25-40 standard servers a week once templates are tuned. Programmes with two or three squads reach 60-120 a week. Velocity is usually limited by app owner readiness and testing, not by tools.
How long does it take to set up a factory?
Three to four weeks to load the backlog, agree the intake gate, build templates and staff squads, followed by two or three pilot waves. Full velocity is usually reached between weeks 8 and 12. Existing programmes can switch to the factory model mid-flight.
What does a migration factory cost?
Factories are usually priced per server or per squad-month. Per-server rates for standard rehost work often fall to INR 8,000-15,000 at volume, lower than one-off projects. Complex workloads are priced separately. We show the cost-per-server trend in the weekly report.
Can our internal team and partners work in the same factory?
Yes. Squads can mix internal staff and partner engineers, using one backlog, one intake gate and one calendar. We recommend the wave lead role sits with one accountable party, and that all squads use the same templates and reporting. Shared metrics make each party's throughput visible.
How do you plan around Indian business calendars?
The wave calendar marks quarter-end and year-end closes, GST return dates, festive peaks such as Diwali, and plant shutdowns. Regulated entities also block periods around RBI, SEBI or IRDAI submissions. Waves are not scheduled in frozen windows. Plant shutdowns can also become migration windows.
What is the tail and how is it handled?
The tail is the 10-20% of workloads that are hard to move, such as unsupported OS versions, vendor-locked apps or large databases. We start a separate tail plan by month three with specialists, so it runs alongside the factory instead of after it.