How long does an Azure migration take?

The assessment is typically a few weeks, and most of that is waiting rather than working: dependency data has to be collected over a period long enough to capture month-end processing and other periodic workloads, and cutting that short is how dependencies get missed. Migration itself scales with the number of waves rather than the number of servers, since a wave is a weekend regardless of whether it contains five machines or twenty. A mid-sized estate is commonly a few months end to end. What extends it is not the moving but the treatments that are not rehost, since refactoring and replacement need test cycles that cannot be compressed.

Will this cost less than our current infrastructure?

It can, and it will not automatically, and the difference is right-sizing. On-premises servers were specified for a five year peak with headroom, because that is how capital purchasing works. Carrying that sizing into a consumption model means paying every month for capacity that was bought once and mostly unused. Migrations that carry existing specifications across reliably produce a bill higher than the projection. Migrations that right-size against measured utilisation, retire what has no users, and schedule non-production off outside working hours generally land close to the assessment. We do not publish figures because they depend entirely on your estate, and Azure pricing is published directly by Microsoft.

What is Azure Migrate and does it cost anything?

It is Microsoft free hub for discovering and assessing on-premises workloads before migration. It discovers across VMware, Hyper-V, physical servers and AWS, collects utilisation data, performs agent-based dependency mapping between machines, and produces right-sized Azure recommendations along with cost projections over one, three and five years. The tooling itself carries no licence cost. What an engagement costs is the work of deploying it properly, running the collection for a representative period, and interpreting the output with your application owners, which is the part that determines whether the migration is any good.

Can we move everything, or should some things stay?

Some things should stay, and a hybrid outcome is a legitimate result rather than a failed migration. The recurring categories are latency-bound systems on a manufacturing floor, applications with a hard dependency on local equipment, and software licensed per physical core in a way that makes cloud hosting genuinely uneconomic. There is also a category worth separating out: workloads that should neither move nor stay, but be turned off. Every assessment we run finds servers with no users and no owner that nobody was confident enough to stop, and retiring those is the cheapest possible migration outcome.

What happens to our databases?

The mechanical answer is Azure Database Migration Service, which handles SQL Server, MySQL and PostgreSQL. The interesting decision is whether to keep running them on a virtual machine or move to a managed service. Managed removes patching, backup and high availability work permanently, which is a substantial ongoing saving in effort rather than only in cost, and it costs you some configuration flexibility that most applications never use. We assess each database individually, because the answer differs, and because a database with an unusual configuration or a vendor support requirement may genuinely need to stay on a virtual machine.

How do we get the data there if our connectivity is limited?

Measure the link before planning around it, because Indian connectivity varies enough between cities and buildings that assumptions are unreliable. For most workloads, replication over the network works well, because tools like Azure Site Recovery replicate continuously ahead of cutover rather than copying everything on the night. Where the estate includes large file shares or archives, the arithmetic sometimes does not work, and Azure Data Box handles bulk physical transfer instead. That calculation takes an hour and should happen during assessment, because discovering it on cutover weekend is a much worse experience.

What if something goes wrong during cutover?

You roll back, and the reason that is realistic is that replication-based migration keeps the source running until you decide to commit. Azure Site Recovery replicates continuously, so cutover is a controlled failover rather than a one-way copy, and the on-premises workload is still there if the migrated one misbehaves. What makes rollback actually work is having tested it rather than documented it, and having a named person available on cutover night with authority to make the call. Rollback decisions that wait until the following morning are how a bad weekend becomes a bad week.

Do we need to change how we manage things afterwards?

Yes, and underestimating this is a common source of disappointment. Cloud operations are not the same as server operations: cost management becomes a continuous discipline rather than an annual purchase, resources are easy to create and therefore easy to forget, and tagging is the only thing standing between you and a bill nobody can explain. Patching, backup and monitoring all still exist, they simply move. We build the landing zone with those disciplines in place and hand over documentation, and where clients would rather not build the capability internally we manage the estate on an ongoing basis instead.

Can you do this remotely? We are not in Hyderabad.

Largely yes. Discovery, assessment, landing zone construction and the migration waves themselves are delivered remotely, and that is how most of our Azure engagements run. The exceptions are physical: the initial appliance deployment sometimes benefits from being on site depending on your environment, and decommissioning physical hardware afterwards obviously needs hands. We are based in Gachibowli, Hyderabad and work with organisations across India, with senior engineers travelling for the parts that genuinely need presence. Initial enquiries get a reply within 4 business hours.

Azure migration, India

Lifting your servers into Azure unchanged gets you the same estate with a monthly bill. The assessment is what decides whether it was worth doing.

Most disappointing Azure migrations were rehosts that should have been retirements. Azure Migrate discovers what you actually run, maps the dependencies nobody documented, and produces a right-sized recommendation per workload against the six treatments: rehost, refactor, rearchitect, rebuild, replace, retire. Doing that properly is where the value comes from. We run the assessment first, and we are direct about the workloads that should not move at all.

Book an Azure migration assessment See what the assessment covers

Azure cloud migration assessment and delivery for Indian organisations

6 treatmentsNot one, and not all rehost
Free assessmentAzure Migrate costs nothing
4 India regionsHyderabad live mid-2026
DependenciesWhat breaks a phased move

What the work involves

Eight things that decide whether an Azure migration pays off.

The technical act of moving a server is the easy part and the part vendors talk about. What determines the outcome is the eight decisions around it, most of which are made before anything moves and are expensive to revisit afterwards.

Discovery of what you actually run

Azure Migrate discovers across VMware, Hyper-V, physical servers and AWS, building an inventory with utilisation data rather than a list somebody maintained by hand. Almost every assessment we run finds servers nobody could name an owner for, workloads that have not been accessed in a year, and at least one application running on hardware everybody believed was decommissioned. The discovery is free and it is consistently the most surprising deliverable.

Dependency mapping, which is what breaks phased moves

Servers talk to each other in ways nobody documented, and a phased migration that separates two chatty systems across a WAN link produces an application that technically works and is unusably slow. Agent-based dependency mapping shows the actual traffic between machines, which is how migration waves get grouped correctly. Skipping this is the single most common cause of a migration that has to be partially rolled back.

A treatment decision per workload, not one strategy

The 6R framework exists because different workloads deserve different answers. Rehost for the ones that just need to be somewhere else. Refactor where a small change unlocks a managed service. Replace where a SaaS product does the job better than the thing you built. And retire, which is the treatment nobody proposes and which frequently applies to more of an estate than anybody expects. A migration that is entirely rehost has usually skipped this step.

Region and availability zone selection

Central India in Pune, West India in Mumbai and South India in Chennai are live, and South Central India in Hyderabad is Microsoft largest India datacentre, going live mid-2026 with three availability zones and Central India as its paired region. Region choice affects latency to your users, data residency commitments, which services are available and how your disaster recovery pairing works, so it is a decision worth making deliberately.

A landing zone built before anything moves

Subscriptions, management groups, networking, identity, policy, tagging and role-based access, established before the first workload arrives. Migrating into an unstructured subscription is how organisations end up with resources nobody owns, costs nobody can attribute and a security posture assembled retrospectively. This is unglamorous, it takes real time, and it is what separates a migration from a mess.

Databases, which move differently from servers

Azure Database Migration Service handles SQL Server, MySQL and PostgreSQL, and the interesting decision is not how to move them but whether to keep running them on a virtual machine or move to a managed service. Managed removes patching, backup and high availability work permanently, at the cost of some configuration flexibility. That trade is worth making explicitly rather than defaulting to lift-and-shift because it is simpler.

Getting the data there, which is a bandwidth problem

Replication over the network works well for most workloads and badly for large file estates, and Indian connectivity varies enough between cities that this needs checking rather than assuming. Azure Data Box handles bulk physical transfer where the network genuinely cannot carry it in a sensible window. The calculation is simple and it is worth doing early, because discovering it at cutover weekend is the wrong time.

Cutover, rollback and the week afterwards

Azure Site Recovery replicates continuously so cutover is a controlled failover rather than a copy under time pressure, which also means a tested rollback exists if something is wrong. What matters as much is the fortnight after: right-sizing against real utilisation, closing the on-premises footprint you no longer need, and confirming backup and monitoring actually followed the workload rather than being assumed.

The six treatments

What each one means, when it applies, and what it costs you.

The assessment output is a treatment per workload. This is how we decide which, and being honest about the last two is where most of the value in an assessment actually sits.

Rehost, the default that is overused

Move the virtual machine as it is. Fastest, lowest risk, and it delivers a datacentre exit rather than a modernisation. Legitimate for a great deal of an estate and a poor answer for all of it.

Right when the driver is a lease ending or hardware refresh due
Wrong as a universal strategy, since it carries every existing problem across
Plan a right-sizing pass afterwards, because on-premises sizing is usually generous

Refactor, small change for a large operational gain

Minor modification so a workload can use a managed service, most commonly moving a database off a virtual machine or a web application onto App Service. Modest effort, permanent reduction in operational work.

Best value per unit of effort in most assessments we run
Removes patching, backup and high availability work for good
Needs a real test cycle, so it is not a cutover weekend decision

Rearchitect, when the shape is the constraint

Meaningful redesign so an application can scale or be maintained properly. Real project work with real cost, justified when the current architecture is actively holding the business back rather than merely being old.

Justify it on a business constraint, not on architectural preference
Rarely belongs inside a migration programme, better sequenced after
Rehost first and rearchitect later is usually the lower-risk path

Rebuild, when what exists cannot be carried forward

Start again on cloud-native services. Appropriate where the existing application is unmaintainable, unsupported, or depends on something that simply does not exist in Azure.

Usually forced rather than chosen, by an unsupported dependency
Keep the old system running in parallel until the new one is proven
The longest path, so do not put it on the migration critical path

Replace, where somebody already built it better

Retire the workload and adopt a SaaS product instead. Frequently the right answer for file servers, internal wikis, ticketing, HR systems and anything else where your bespoke version is not a differentiator.

Ask what the application does that a product could not
Data migration and process change are the real cost, not the licence
Removes a workload from your estate permanently rather than relocating it

Retire, the treatment nobody proposes

Turn it off. Every assessment we run finds workloads with no users, no owner and no purpose anybody can articulate, kept running because nobody was confident enough to stop them.

Usually more of the estate than anybody expects before discovery
Power off and observe for a period before decommissioning properly
The cheapest possible migration outcome, and the least often recommended

And the workloads that should not move

Some things belong on premises: latency-bound manufacturing systems, equipment with a hard local dependency, and applications whose licensing makes cloud hosting genuinely uneconomic.

Shop-floor and OT systems with real-time constraints
Software licensed per physical core in a way that punishes virtualisation
A hybrid answer is a legitimate outcome, not a failed migration

How the treatments get agreed

The assessment proposes, the business decides. We present each workload with its treatment, the reasoning, the effort and the risk, and we expect several to be argued about, because the people who use a system know things the telemetry does not.

Application owners review the recommendation before it is fixed
Disagreements usually surface a dependency the tooling missed
The agreed treatment list becomes the migration plan and the budget

Why bring us in

We assess honestly, including when the answer is do not move it.

Assessment first, and it costs you nothing in tooling

Azure Migrate is free, so the discovery and dependency mapping that determine the whole shape of a migration carry no licence cost. What they need is somebody to run them properly and interpret the output with your application owners, which is where we spend the time.

We will tell you what should not move

Every assessment we run recommends some retirements, some replacements and occasionally that a workload stays on premises. That reduces the size of the engagement and it is the right answer, and a partner whose assessment concludes that everything should be rehosted has not really done one.

Hyderabad based, with a new Azure region on our doorstep

South Central India in Hyderabad is Microsoft largest India datacentre and goes live mid-2026 with three availability zones. For Hyderabad organisations that changes the latency and residency conversation, and it is worth factoring into region choice rather than defaulting to Central India out of habit.

We run estates afterwards, so we build for operation

A migration partner who leaves at cutover has no reason to care about tagging discipline, monitoring coverage or whether anybody can attribute the bill. We manage estates for clients continuously, so the landing zone we build is one we would be willing to operate.

What drives the project

Why Indian organisations move to Azure.

A datacentre or colocation lease ending

The most common trigger and the one with a hard date attached. Timeline pressure makes rehost tempting for everything, which is exactly when an assessment saves the most, because retirements shrink the work.

A hardware refresh nobody wants to fund

Servers out of warranty and a capital request nobody wants to approve. The comparison is genuinely favourable here, provided the estate is right-sized rather than carried across at its existing specification.

BFSI and regulated workloads

Data residency and sectoral requirements make region choice and the paired region for disaster recovery a compliance decision rather than a technical preference. Usually needs documenting for a regulator rather than merely deciding.

Manufacturing with a hybrid outcome

Business systems move, shop-floor and operational technology stays, and the interesting work is the connectivity and identity model between them. A hybrid result here is the correct answer rather than an incomplete migration.

Healthcare with clinical system constraints

Clinical applications frequently carry vendor support restrictions on where they may run, so the assessment has to include a vendor conversation. Getting that wrong invalidates support at the worst possible moment.

Education and seasonal demand

Admissions and results periods create load an on-premises estate has to be permanently sized for. This is the workload profile where elasticity genuinely changes the economics rather than merely relocating them.

Region choice

The Indian Azure regions, and what each one means for you.

Region is a decision with latency, residency, service availability and disaster recovery consequences, and it is frequently made by accepting a default. Worth ten minutes of deliberate thought, particularly with a new Hyderabad region arriving.

	Region	Status
Central India, Pune	Live, and the most commonly used Indian region	Broad service availability and the paired region for South Central India, which makes it relevant to disaster recovery design even if your workloads sit elsewhere.
West India, Mumbai	Live	Strong choice for organisations concentrated in Mumbai and the western corridor. Check service availability for anything specialised, since not every service reaches every region simultaneously.
South India, Chennai	Live	Serves the southern corridor. As with West India, confirm the specific services you need are available rather than assuming parity with Central India.
South Central India, Hyderabad	Going live mid-2026, three availability zones	Microsoft largest India datacentre, paired with Central India. For Hyderabad and Telangana organisations this changes the latency and residency conversation, and availability zones matter for anything needing in-region resilience.
Availability zones	Where supported in region	Protection against a single datacentre failure without leaving the region, which is a different problem from regional disaster recovery and needs designing separately.
Paired regions	Fixed by Microsoft, not chosen	Determines where certain replicated services can fail over to. Worth understanding before designing recovery, because it constrains the options rather than expanding them.

Two migrations

Lift-and-shift everything against an assessed migration.

Both end with your workloads in Azure. One produces a datacentre exit and a larger monthly bill; the other produces a smaller estate that costs less to run than it did.

Feature	Dimension	Lift-and-shift everything
Starting point	The server list from your virtualisation console	Discovery with utilisation and dependency data
Workloads that move	All of them	The ones that should, after retirement and replacement
Sizing	Matched to existing on-premises specification	Right-sized against measured utilisation
Databases	Stay on virtual machines	Assessed for managed services where they fit
Wave planning	By convenience or alphabetically	By dependency group, so nothing is split
Landing zone	Assembled as workloads arrive	Built and tested before the first wave
Estate afterwards	The same estate, hosted elsewhere	Smaller, with operational work permanently removed
The monthly bill	Higher than expected, and hard to attribute	Projected in advance, tagged and attributable

The bill after month one is not the bill you were shown.

Azure assessments produce a cost projection based on right-sized recommendations, and organisations frequently migrate at their existing on-premises sizing instead, because it feels safer. On-premises servers were specified for a five year peak with headroom on top, so carrying that sizing into a consumption model means paying monthly for capacity that was bought once and never used. The right-sizing pass after cutover is not optional tidying, it is where the economics of the migration actually land.

Migrate at assessed sizing where you can, and right-size within weeks where you cannot
Reserved capacity and licensing benefits change the picture and need deciding deliberately
Turn off non-production outside working hours, which is free and frequently forgotten
Decommission the on-premises footprint, or you are paying for both indefinitely

The engagement

Five stages, and two of them happen before anything moves.

1
Discover and map dependencies
Azure Migrate deployed against your estate, collecting inventory, utilisation and agent-based dependency data over a period long enough to capture month-end and other periodic workloads. Rushing this window is how a dependency gets missed, so we run it for long enough to be representative rather than for long enough to be convenient.
2
Assess, and agree a treatment per workload
Right-sized recommendations, dependency groupings and a proposed treatment for every workload, reviewed with application owners rather than handed over as a report. Expect argument, and expect it to be productive, because the people who run a system know things the telemetry cannot see.
3
Build the landing zone
Subscriptions, management groups, networking, identity, policy, tagging and access model, built and tested before any workload arrives. Plus the connectivity to on premises, measured rather than assumed, because that number determines your replication and cutover windows.
4
Migrate in dependency-grouped waves
Replication running continuously ahead of each wave, a tested rollback, and cutover as a controlled failover rather than a copy against the clock. Waves grouped so systems that talk to each other move together, starting with something low risk to prove the process end to end.
5
Right-size, decommission, and hand over
Utilisation reviewed against actual usage in the weeks after each wave, sizing corrected, non-production scheduled off outside working hours, and the on-premises footprint properly decommissioned. Then documentation and handover, or ongoing management if that is what you want.

Before the first wave

Twelve things to have settled before anything moves.

The list we work through before scheduling a first migration wave. Most migration trouble traces back to one of these being assumed rather than confirmed.

The landing zone

Subscription and management group structure agreed
Retrofitting this later is genuinely painful
Network topology and connectivity to on premises tested
Bandwidth and latency measured, not estimated
Identity model decided, and hybrid identity working
Entra Connect health checked before, not during
Tagging and cost attribution in place from day one
Untagged resources become unattributable spend

The workloads

Every workload has an agreed treatment and an owner
Including the ones agreed for retirement
Dependency map reviewed by application owners
Tooling misses things people know about
Waves grouped so chatty systems move together
The commonest cause of a rolled-back move
Licensing checked, particularly per-core products
This changes some treatment decisions entirely

The safety net

Rollback tested, not just documented
Site Recovery makes this genuinely achievable
Backup configured in Azure before cutover, not after
A workload with no backup is not migrated
Monitoring and alerting following the workload
Frequently assumed and frequently absent
A named decision maker available on cutover night
Rollback decisions cannot wait until morning

Questions we get asked

Azure migration, answered plainly.

What sits either side of this.

Cloud migration services

The wider cloud practice, including the Microsoft 365 side and the mixed estates that do not fit a single migration pattern.

Learn more

Google Workspace to Microsoft 365

The collaboration platform migration that often runs alongside an infrastructure move, and where Drive rather than mail decides the schedule.

Learn more

Exchange to Exchange Online

Mail is usually the first workload out of a datacentre, and the one with the most undocumented dependencies attached to it.

Learn more

Next step

Start with the assessment, since the tooling is free.

Azure Migrate costs nothing and the discovery is consistently the most useful deliverable of the whole programme, because it tells you what you actually run and what genuinely needs to move. Tell us roughly how many servers you have and what is driving the timeline. Remote-first from Hyderabad, serving all of India.

Book an Azure migration assessment See our wider cloud practice

Related Services

Explore more solutions that work great with this service

Lifting your servers into Azure unchanged gets you the same estate with a monthly bill. The assessment is what decides whether it was worth doing.

Eight things that decide whether an Azure migration pays off.

Discovery of what you actually run

Dependency mapping, which is what breaks phased moves

A treatment decision per workload, not one strategy

Region and availability zone selection

A landing zone built before anything moves

Databases, which move differently from servers

Getting the data there, which is a bandwidth problem

Cutover, rollback and the week afterwards

What each one means, when it applies, and what it costs you.

Rehost, the default that is overused

Refactor, small change for a large operational gain

Rearchitect, when the shape is the constraint

Rebuild, when what exists cannot be carried forward

Replace, where somebody already built it better

Retire, the treatment nobody proposes

And the workloads that should not move

How the treatments get agreed

We assess honestly, including when the answer is do not move it.

Assessment first, and it costs you nothing in tooling

We will tell you what should not move

Hyderabad based, with a new Azure region on our doorstep

We run estates afterwards, so we build for operation

Why Indian organisations move to Azure.

A datacentre or colocation lease ending

A hardware refresh nobody wants to fund

BFSI and regulated workloads

Manufacturing with a hybrid outcome

Healthcare with clinical system constraints

Education and seasonal demand

The Indian Azure regions, and what each one means for you.

Lift-and-shift everything against an assessed migration.

The bill after month one is not the bill you were shown.

Five stages, and two of them happen before anything moves.

Discover and map dependencies

Assess, and agree a treatment per workload

Build the landing zone

Migrate in dependency-grouped waves

Right-size, decommission, and hand over

Twelve things to have settled before anything moves.

The landing zone

The workloads

The safety net

Azure migration, answered plainly.

How long does an Azure migration take?

Which Azure region should we use?

Will this cost less than our current infrastructure?

What is Azure Migrate and does it cost anything?

Can we move everything, or should some things stay?

What happens to our databases?

How do we get the data there if our connectivity is limited?

What if something goes wrong during cutover?

Do we need to change how we manage things afterwards?

Can you do this remotely? We are not in Hyderabad.

What sits either side of this.

Cloud migration services

Google Workspace to Microsoft 365

Exchange to Exchange Online

Start with the assessment, since the tooling is free.

Related Services

Cloud Migration

Server Management

Disaster Recovery

Data Backup