A server migration costs more than the supplier quote
Moving a workload is not only a matter of copying bytes from a source to a target.
A team must configure replication, grant access, validate applications and databases, change network and storage dependencies, execute cutover, and stabilize the new environment.
The old and new environments may run at the same time, while a service interruption can destroy contribution profit and leave employees unable to do productive work.
This estimator models up to ten migration waves.
It separates initial copy time from the time required to catch up with data that keeps changing, then combines internal person-hours, external quotes, shared tools, contingency, dual running, and probability-weighted downtime loss.
The output is a planning scenario for budget and cutover review, not a fixed bid or a zero-downtime guarantee.
Four decisions this calculator supports
- Can the measured transfer path catch up with daily changes before cutover?
- How much budget is required after labor, dual running, and business interruption are included?
- Does the approved budget tolerate the planned outage and a rollback stress case?
- Which wave drives the schedule and peak planning cash?
Migration project cost versus long-term hosting TCO
A cloud server versus managed hosting TCO comparison asks which operating model is less expensive after migration.
This calculator asks a different question: what will one migration project cost when transfer, testing, refactoring, cutover, rollback readiness, overlapping environments, and interruption are included?
The lowest monthly platform cost does not automatically produce the lowest or safest migration project cost.
Scope boundary between migration project cost and long-term hosting TCO| Dimension | This calculator | Hosting TCO comparison |
|---|
| Decision | Project budget, waves, and cutover window | Target operating model |
| Time horizon | Replication through cutover and stabilization | Monthly and multi-year operations |
| Main inputs | Data, change rate, throughput, labor, cutover, rollback | Resources, monthly charges, support, operations, SLA |
| Main outputs | Catch-up time, downtime loss, economic total, peak cash | Nominal and PV TCO, break-even, sensitivity |
Build an evidence-based input set
The strongest inputs come from current bills, an asset inventory, database telemetry, transfer tests, recovery rehearsals, supplier quotes, and a work breakdown structure.
Early assumptions are useful for discovering missing scope, but an approval model should name the owner and observation date for each important value.
Inventory and logical data
Count physical servers, logical servers, VMs, and databases without duplicate ownership. Confirm whether snapshots, backups, empty blocks, and archived objects are inside the transfer scope.
Bandwidth and change rate
Use measured throughput on the intended path, with the intended encryption and file profile. Model an ordinary day and a peak change day separately.
Internal person-hours
Include replication setup, monitoring and retry work, functional and non-functional tests, dependency changes, cutover, validation, and stabilization.
Quotes and dual running
Align tax treatment, currency, exclusions, payment timing, source run cost, and target run cost. Include temporary transfer or storage services when they are not inside the base quote.
Business interruption
Apply contribution margin to affected hourly revenue, then add labor that is genuinely idle. Remove overlap if payroll is already represented in the contribution figure.
Probability and budget
Use rollback and overrun frequencies only when rehearsals or deployment history support them. Present the expected case next to the worst case when the evidence is weak.
Transfer time and change catch-up formula
The estimator uses decimal units, so one terabyte equals 8,000,000 megabits.
Effective bandwidth is nominal Mbps multiplied by the editable utilization rate, and daily capacity is effective bandwidth multiplied by 86,400 seconds.
Core equations
effective Mbps = nominal Mbps × utilization.
initial copy hours = data TB × 8,000,000 ÷ effective Mbps ÷ 3,600.
daily changed data = data TB × daily change rate.
net catch-up capacity = daily transfer capacity − daily changed data.
synchronized transfer hours = data TB ÷ net catch-up capacity × 24.
An effective 1,000 Mbps path has a theoretical daily capacity of 10.8 TB.
If a 1 TB source changes by 10%, or 0.1 TB per day, net catch-up capacity is 10.7 TB per day and synchronized transfer takes about 2.24 hours.
If daily changes equal or exceed daily transfer capacity, the continuous model cannot converge and the calculator rejects the input.
Why measured throughput matters
Small files, compression, deduplication, encryption, source and target IOPS, retransmission, throttling, competing traffic, and tool limits can all reduce throughput.
The utilization input can represent those effects, but it does not replace a test using production-like data and the intended network path.
Direct migration and dual-running cost
Each wave adds replication setup, transfer monitoring, testing, refactoring, and cutover person-hours.
Multiplying those hours by loaded internal labor cost creates an internal economic cost, which is added to wave-level external quotes and shared tools, travel, and other fixed costs.
The selected contingency percentage applies to that direct-cost subtotal.
Direct migration and dual-running cost equations| Cost layer | Calculation | Evidence to retain |
|---|
| Internal labor | Total person-hours × loaded hourly cost | Work breakdown, roles, compensation basis |
| Base direct cost | Labor + external + tools + travel + other | Quotes, contracts, exclusions, tax basis |
| Direct migration cost | Base direct cost × (1 + contingency rate) | Risk register and contingency approval |
| Dual-running cost | (Source monthly + target monthly) × days ÷ 30 | Invoices, proration, commitments, exit date |
The 30-day month is a planning convention.
If a provider charges a full calendar month, a minimum term, egress, prepaid credits, or an early-exit charge, add the evidenced amount to shared or wave external cost.
Expected and worst-case downtime loss
Hourly business loss equals affected hourly revenue multiplied by contribution margin, plus idle staff multiplied by idle labor cost.
Planned downtime is certain inside the scenario.
Expected downtime adds rollback probability multiplied by rollback time and overrun probability multiplied by the common overrun time for each wave.
Worst-case downtime adds all three durations without probability weighting.
Planned
The service interruption required by the normal cutover runbook.
Expected
Planned time plus probability-weighted rollback and overrun time.
Worst case
Planned, rollback, and overrun time all occur in every wave.
Budget-allowable downtime is calculated by subtracting direct migration and dual-running cost from the approved total budget, then dividing the remainder by hourly business loss.
It is zero when non-downtime cost already consumes the budget, and it is unavailable when the budget or hourly loss is zero.
Reputation, contractual damages, SLA credits, customer churn, and data-loss exposure are not invented by the model; include only an approved amount or manage them in a separate risk register.
Worked example
The following values explain the arithmetic and are not a market benchmark.
Assume one 1 TB wave on an effective 1,000 Mbps path, no continuing changes, 24 person-hours, two people working eight hours per day, two planned outage hours, a 20% rollback probability with three additional hours, and a 10% overrun probability with two additional hours.
Use $100 per loaded person-hour, $1,000 of wave external cost, $1,000 of shared cost, 10% contingency, and $1,500 of dual-running cost.
Illustrative one-wave server migration result| Output | Illustrative value | Interpretation |
|---|
| Initial and synchronized transfer | 2.22 hours | The values match because change rate is zero. |
| Direct migration cost | $4,840 | Labor, external, shared cost, and 10% contingency. |
| Expected downtime | 2.8 hours | 2 + 20% × 3 + 10% × 2. |
| Expected downtime loss | $9,240 | 2.8 hours at $3,300 per hour. |
| Expected economic total | $15,580 | Direct + dual running + expected downtime loss. |
| Allowable downtime at a $20,000 cap | About 4.14 hours | The outage ceiling implied by the budget. |
Worst-case economic cost is $29,440 in the same example.
The gap between $15,580 and $29,440 is the practical reason to approve rollback authority and risk funding alongside the central estimate.
Step-by-step workflow
- Set the transfer basis. Enter nominal Mbps, measured utilization, concurrent team size, and productive hours per day.
- Create dependency-aware waves. Group inventory that must share a cutover and enter data volume and daily change rate.
- Translate the work breakdown into person-hours. Separate replication, monitoring, testing, refactoring, and cutover effort.
- Record planned and rollback time. Keep normal outage duration separate from additional recovery duration measured in rehearsal.
- Add actual quotes and overlap. Align external, tool, travel, source, and target costs on one currency and tax basis.
- Define interruption economically. Use contribution profit and non-overlapping idle labor, then enter the approved budget cap.
- Review expected and worst results together. Check allowable downtime, funding gap, peak wave, and catch-up warnings.
- Recalculate after rehearsal. Replace throughput, task duration, and rollback assumptions with measured evidence and update the runbook.
Common migration scenarios
Data center or colocation move
Put physical handling, freight, rack work, and field services in external wave cost while keeping network replication and application validation in person-hours.
Add temporary replacement infrastructure to dual running when it carries production traffic.
On-premises to cloud
Separate full copy from continuing replication and include evidenced transfer service, temporary storage, egress, and support costs.
Compare long-term cloud operation in a separate TCO decision.
Cloud-to-cloud migration
Include source egress, target staging, identity and observability changes, and rebuild effort.
Test the actual provider, region, routing, and encryption path rather than reusing a generic Mbps assumption.
Database-led cutover
Measure peak change volume, final synchronization, write freeze, validation, and rollback data handling separately.
The estimator cannot select a replication method or certify data consistency.
Interpret the result as an action list
- When synchronized time is much longer than initial copy time, review change rate, reserved bandwidth, replication parallelism, or wave size.
- When expected cost fits but the worst case does not, define rollback authority, a fix-forward time limit, and risk contingency.
- When allowable downtime is shorter than planned downtime, consider smaller waves, pre-synchronization, read-only operation, phased traffic, or a larger budget.
- When peak wave funding is large, rebuild the output as a contract-based monthly cash schedule with deposits, milestones, and credits.
- When downtime dominates the total, verify the affected revenue boundary, contribution margin, and idle-labor overlap before changing architecture.
- When every quote is zero, use the schedule only and do not treat the economic total as purchase approval evidence.
Limitations and controls outside the model
The calculator does not replace
- Application and database dependency discovery, consistency design, RPO, RTO, or recovery engineering.
- Performance, security, privacy, licensing, regulatory, contractual, tax, or accounting review.
- DNS TTL, certificates, allowlists, external integrations, batch jobs, and message idempotency.
- Provider service limits, tool compatibility, actual prices, exchange rates, and vendor fitness.
- Reverse replication or reconciliation of new transactions after rollback.
- Parallel-resource contention, night or weekend premiums, fatigue, and approval delay.
Wave duration conservatively adds synchronized transfer, team workdays, and planned outage, then schedules waves sequentially.
Real projects may overlap transfer and testing, but the estimator does not shorten a plan without dependency and resource evidence.
Wave planning cash allocates shared cost and dual running in proportion to direct wave cost; it is not a contract payment calendar.
Frequently asked questions
Why is there no average server migration price?
Architecture, data profile, path, transformation scope, outage tolerance, and contract terms vary too widely for one reliable market price. The estimator combines your evidenced quotes and loaded labor instead.
What bandwidth utilization should I enter?
Run a transfer test over the intended route with the intended security and representative file profile. Use actual throughput divided by nominal Mbps, and model more than one scenario when evidence is limited.
How do I measure daily change rate?
Use database logs, CDC metrics, storage changed bytes, or incremental backup volume over a consistent 24-hour window. Compare an ordinary day with a peak business day.
Is expected downtime a statistical forecast?
No. It is a linear planning expectation built from user-entered rollback and overrun probabilities. It does not model correlation or cascading failure, so keep the worst case beside it.
How should an internal system with no revenue be valued?
Use only approved economic effects such as idle labor, overtime, temporary manual work, or delayed production contribution. Do not invent reputation loss.
What if migration waves run in parallel?
The calculator uses a sequential baseline. Overlap tasks later in the project schedule only after confirming dependencies, people, bandwidth, change freezes, and approval gates.
Does this include long-term cloud operating cost?
Only source and target cost during the dual-running period is included. Use a separate cloud-versus-hosting TCO model for ongoing resource, support, labor, availability, and commitment decisions.
Primary sources and verification boundary
The sources below were checked on August 13, 2026.
AWS describes its Pricing Calculator as a planning tool that estimates charges from the information entered, rather than a substitute for actual usage, taxes, and contract billing.
AWS Prescriptive Guidance recommends evaluating business impact, fix-forward contingency, rollback time, functional and non-functional testing, task sequence, owners, rollback criteria, and decision authority before cutover.
AWS DataSync documentation also shows that source and destination support, agents, permissions, network connectivity, locations, and task configuration matter, so a simple bandwidth equation cannot establish tool fitness.
Turn quotes and rehearsal evidence into one migration plan
Use the first estimate to find missing scope, then replace throughput, effort, and rollback assumptions after a production-like rehearsal.
Approving the expected case, worst case, allowable downtime, and peak wave together produces a more executable plan than approving the supplier quote alone.