India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Post Migration Optimization: Fix Sizing, Storage and Leftovers
Post migration optimization is a fixed 60-90 day engagement after workloads move, which corrects the choices made to move fast: oversized VMs copied from on-prem, premium disks everywhere, leftover replication and staging resources, unused licences and untuned databases. NTSPL compares cloud metrics to the on-prem baseline, applies changes in safe batches and hands a cleaned estate to operations.
Delivered on
In scope
Why the First Bill After Migration Exceeds the Business Case
Lift-and-shift moves are sized for safety. A server with 16 cores on-prem lands on 16 vCPUs; every disk becomes premium SSD because nobody wanted a slow cutover; replication servers, staging subnets and test clones remain after the last wave. The first full cloud bill after migration is often 30-50% above the business case, and leadership starts to doubt the programme. Most of that gap is migration residue, not a flaw in the cloud choice.
NTSPL runs optimization as a closing phase of the migration, not as an ongoing FinOps practice. In the first 30 days we collect real metrics, find every resource created by the migration itself and match each VM to its on-prem performance baseline. Then we apply changes in batches: delete residue, right-size compute, move disks to the correct tier, apply licence benefits and tune the slowest queries. The estate is handed to operations clean, with a baseline for ongoing cost management.
Signals Your Migrated Estate Needs a Cleanup Phase
Signals you need Post Migration Optimization
- The first full monthly bill after migration is more than 20% above the business case.
- Migrated VMs average under 20% CPU over 30 days.
- Replication appliances, staging instances or test clones are still running after the last wave.
- Users report slower response on some apps than before migration.
When to choose something else
- If the estate has been in cloud for over a year and needs a full cost practice, see Cloud Cost Optimization & FinOps.
- If migration waves are still running, wait; optimizing a moving estate creates conflicting changes.
Residue Removal, Right-Sizing, Storage, Licences, Tuning
Migration residue sweep
Replication servers, staging disks, snapshots, test clones, temporary links and unused IPs created during migration.
Compute right-sizing
VMs resized against 30 days of cloud metrics and the on-prem baseline, including instance family changes.
Storage tier correction
Disks moved from premium to standard or throughput tiers where IO data allows.
Licence and commitment review
Licence benefits applied, licence-included choices checked, and first commitments sized after resizing.
Performance tuning
Slowest queries, chatty cross-zone calls and misplaced app-database pairs fixed.
Baseline-Compare-Correct Optimization Cycle
Baseline-Compare-Correct Post-Migration Cycle
Cloud metrics are compared with on-prem baselines and a residue inventory to produce a change list. Changes are applied in batches with performance checks, then commitments are sized on the corrected estate.
Select any component
Baseline-Compare-Correct Post-Migration Cycle: click any of its 6 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Sizing and Recommendation Tools by Cloud
Moving migrated EBS volumes from gp2 or io types to gp3 is often the quickest saving; Compute Optimizer analyses a 14-day metrics lookback by default, so its advice is most useful after two weeks.
Migrated VMs often run licence-included Windows or SQL Server when Software Assurance licences exist; Hybrid Benefit is applied without downtime.
Custom machine types let migrated VMs match measured CPU and memory closely, and sustained use discounts apply automatically on eligible machine types.
Post-Migration Choices: What to Resize, When to Commit
When to start resizing
Wait until hypercare ends and 14-30 days of steady metrics exist, and include a month-end if the workload has one. Resizing in week one risks undersizing a server that is busy only at close. Start with residue cleanup, which is safe from day one, then right-size, then disks, then commitments.
How far to right-size
Target peak CPU of 60-70% and memory with 20% headroom. Move down one size at a time for production, two for non-production. Consider newer instance families, such as ARM-based options for Linux workloads that support them, but only after application testing. Never resize database servers without checking memory pressure and IO waits.
Disk tier changes
Most migrated disks are overprovisioned. Move to a standard or general-purpose SSD tier when measured IOPS stays under that tier's baseline for 30 days. Keep premium tiers for database data and log disks with measured need. Snapshot before every change and check app response the next business day. Check database log disks separately.
When to buy commitments
Buy reservations or savings plans only after right-sizing has settled, usually by day 60. Commit to 60-70% of steady compute first; add more after another quarter. Buying commitments in week one locks in oversized capacity, which is one of the most common and costly post-migration mistakes. Review coverage again each quarter after that.
The 90-Day Post-Migration Optimization Plan
Baseline and residue sweep
Metrics collected, residue found and removed with owner checks.
Change list and sign-off
Right-size, disk and licence changes listed with savings and risk.
Batched compute and storage changes
Weekly batches applied with performance checks.
Performance tuning
Slow queries and misplaced workloads fixed.
Commitments and handover
Commitments sized, baseline handed to operations.
What you receive
Gap-to-Business-Case and Performance Measures
| KPI | Typical target |
|---|---|
| Gap between monthly bill and business case | Closed to within 5-10% |
| Migration residue remaining | Zero by day 30 |
| Average CPU on production VMs | 35-60% |
| App response versus on-prem baseline | Equal or better |
Optimization Mistakes Right After Go-Live
| Risk | How NTSPL prevents it |
|---|---|
| Undersizing a server that is busy only at month-end. | Resizing waits for a month-end in the metrics, and changes are reversible within one window. |
| Deleting a resource that looked like residue but was in use. | Every deletion is preceded by a stop, a snapshot and seven days of waiting for complaints. |
| Buying commitments too early on oversized capacity. | Commitments are sized only after resizing settles, usually from day 60. |
Post-migration optimization or an ongoing FinOps programme?
Post-migration optimization is a one-time correction of choices made to move fast, done in the first 90 days: residue, oversized VMs, wrong disk tiers, missed licence benefits. FinOps is the ongoing practice that follows: allocation, budgets, anomaly response and commitment management every month. Do the post-migration phase first; starting FinOps on an uncorrected estate means the first quarter of reports is dominated by migration leftovers. Once the estate matches the business case, hand the baseline to the FinOps or cost operations team.
Key facts: Post Migration Optimization
Post Migration Optimization in Practice
2 Post Migration Optimization scenarios, from Garment export manufacturing and Real estate development, plus related platform case studies.
Garment exporter closes a 46% bill overrun within 75 days of moving to Azure
Real estate developer fixes slow CRM and trims 31% across its AWS and Azure estate
Telecom VAS provider cuts daily pages from 2,300 alerts to 9 actionable incidents
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Post Migration Optimization: Frequently Asked Questions
How much can post-migration optimization save?
For lift-and-shift estates, 20-40% of the first full monthly bill is common. Typical sources are oversized VMs, premium disks without need, licence-included charges where Software Assurance exists, and leftover migration resources. The exact figure depends on how conservatively the migration was sized.
Why not right-size during migration?
Right-sizing during migration adds risk to cutover and uses on-prem metrics that may not reflect cloud behaviour. Launching one size up and correcting with cloud metrics afterwards is safer. We still remove obvious waste, such as idle test servers, during intake.
What does post-migration optimization cost?
A 60-90 day engagement for 100-300 servers typically costs INR 6-18 lakh. It is often priced partly on savings. In most cases, the reduction in the monthly bill covers the fee within two or three months. Fees are fixed per phase.
Will apps slow down after right-sizing?
They should not if done properly. We size against peak, including month-end, keep headroom, change one size at a time and check app response after each batch. Any slowdown is reversed in the next window. Owners approve every change first.
Does optimization change our compliance setup?
No. Resizing and tier changes keep resources in the same Indian regions, with the same encryption and logging. Log retention for CERT-In and data location for DPDP Act 2023 are checked as part of the residue sweep, since temporary resources sometimes miss policies.
What happens after the 90 days?
We hand over a baseline: cost per application, sizing rationale, commitment plan and remaining recommendations. Your operations team or a managed cost service uses it for monthly reviews. It becomes the reference point for every later review and commitment decision.