The whole platform you have seen in this course is new. It was designed in Azure, built in Azure and carries no baggage. But Contoso Airlines did not come into existence with this project: it has been running for twenty years, and in the Barcelona datacenter the systems that hold up a good part of the business are still switched on. The hosting contract expires in eighteen months and management has asked for a decision: renew or migrate.

That decision is not a technical one. Moving a server is easy; the hard part is that once it has been moved the organization knows how to run it, that somebody owns its cost, that the team which used to administer it by hand accepts that it is now deployed by pipeline, and that the migration is planned in waves rather than in one heroic weekend. Most migration projects that fail do not fail because of a networking problem: they fail for lack of a business case, because of incomplete inventories, or because of internal resistance nobody managed.

Microsoft's Cloud Adoption Framework exists for exactly that: it is the guidance covering the full cycle — strategy, plan, ready, adopt, govern and manage — and it treats the cloud as an organizational change with a technical component, rather than the other way round. This lesson works through all of it applied to what is left in Barcelona: the business case with the TCO already calculated, the inventory with Azure Migrate, the six migration strategies with each system assigned, the landing zones, the waves with their calendar and their cutover window, data migration, rollback, change management and datacenter decommissioning with its hidden costs.

Reminder: every figure is illustrative and fictitious. The real TCO of a datacenter depends on contracts, depreciation and staffing that only each organization knows.

1. What is left in Barcelona
2. The Cloud Adoption Framework and its phases
3. Motivations and business case
4. Inventory and assessment with Azure Migrate
5. The six migration strategies
6. Azure landing zones
7. Migration waves and calendar
8. Data migration
9. The cutover window and rollback
10. Change management
11. Datacenter decommissioning
12. What gets innovated afterwards
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

A site-to-site VPN with vgw-contoso-pro already exists, so connectivity is not the problem. The problem is that these six items have dependencies on each other that nobody has ever drawn, and each one has a different owner inside the organization.

Two observations about the framework. First, govern and manage are cross-cutting, not final phases: if they are left until the end, the migration creates in three months the mess that will take two years to clean up. Second, adopting is not just migrating: Contoso already innovated — it built the new platform — before migrating the old, and that order is more common than the diagrams suggest.

The motivations determine the order and the success criteria for the whole migration, so it is worth ranking them explicitly:

The business case compares the current TCO with the expected cost in Azure plus the cost of the project itself. You already have the starting figure: the real TCO of the Barcelona datacenter is €340,000/year, a number that includes what almost nobody counts at the beginning.

With those numbers the return arrives around the second year, and that is exactly the message to give management: it is not an immediate saving. Promising savings in the first month is the fastest way to lose the project's credibility, because during the migration you pay for both things at once: the datacenter that has not been switched off yet and the Azure that is already switched on.

Azure Migrate is the hub from which you discover, assess and move. Its value is not in the replication engine — that is the easy part — but in dependency discovery, which is what reveals the surprises.

The result of discovery at Contoso, with the classic surprise:

The five ownerless servers illustrate why discovery is done before planning: two of them were receiving traffic, so switching them off "because nobody claims them" would have broken something. The rule is to switch them off in a controlled way first — a temporary disconnection with monitoring — and only retire them if nobody complains.

Contoso's assignment, which is where the judgment shows:

Note the most important row: not everything gets migrated. An honest migration plan has a "stays" column and a "retire" column, and both improve the outcome.

A landing zone is the environment prepared before the first workload arrives: identity, network, governance, security, observability and subscription organization already resolved, so that every application that lands inherits all of it instead of improvising it.

What it solves, and what otherwise gets solved badly thirty times over:

Contoso already has an embryonic landing zone, and that is the good news of the project: mg-contoso with mg-contoso-plataforma and mg-contoso-cargas, the "Base de gobernanza de Contoso" initiative, the hub with its firewall and VPN, the single log workspace and the Entra ID groups are exactly the platform components of a landing zone. What is missing for the Barcelona workloads is a new subscription for the migrated workloads, an extension of the addressing plan and hybrid name resolution.

Implementation options, from least to most formal: start with a start-small landing zone and mature it later; deploy the enterprise-scale landing zone accelerator, which creates the full hierarchy with its policies; or build it to measure with Bicep, which is the natural choice when you already have your own templates such as contoso-infra. Contoso picks the third: extend what it already has.

Migrating everything at once is the surest way to fail. Workloads are grouped into waves, each with its window, its success criteria and its rollback plan.

Criteria for grouping: by dependency — things that talk to each other travel together — by increasing risk — the easy first, in order to learn — by business calendar — never during the tax close or high season — and by team capacity, which is the real limit.

The pilot in wave 1 is not chosen for its importance but for its ability to teach: the file server touches networking, identity, permissions and real users, with low impact if something goes wrong. A pilot that teaches nothing is a wasted pilot; one that can take the business down is not a pilot.

And billing goes last deliberately, despite being the most urgent on licensing grounds: it is the highest-risk one, and by the time it arrives the team will have executed four migrations. Its window also avoids the quarterly close.

Data is the part that admits no improvisation, because it is the only one that cannot be repeated without consequences.

A decision rule about volume: calculate the real transfer time against the available bandwidth after subtracting production traffic. Twelve terabytes over a shared 200 Mbps link are not "a few hours"; with luck they are several days of continuous transfer, and that is why Data Box exists.

For databases, the pattern that minimizes risk is always the same: initial load, continuous replication, parallel validation, short cutover. Parallel validation — comparing counts, checksums and a few business reports between source and destination before cutting over — is what turns the cutover into a formality.

The two elements that make this work are the decision point at a fixed time and the untouched source. Without a fixed time, a troublesome cutover drags on "just a bit longer" until there is no time left to go back; and rollback is only possible if the original system has not been touched and you know what data has been written to the destination since the cutover. That is why the success and rollback criteria are written beforehand, when nobody is tired or under pressure.

This is where migrations that were going fine technically end up failing. After migrating, people's jobs change:

New roles that appear, and which are worth naming explicitly so that somebody fills them: a platform team — owner of the landing zone, the templates and the guardrails — FinOps — Nuria, with real dedication rather than as a leftover task — and SRE or service operations — owner of alerts, on-call and reliability.

Internal resistance is a project risk every bit as real as a technical incompatibility, and it is almost always justified: somebody who has spent fifteen years administering servers hears "we're migrating to the cloud" as "your job is going away". What works, in order: train before migrating, not after; give those people ownership of the new environment instead of bringing somebody in from outside to do it; make it explicit that their knowledge of the applications and the business is irreplaceable; and communicate honestly about what changes. What does not work: promising that nothing will change.

Migrating does not end when the last machine starts up in Azure: it ends when the contract is terminated, and that is where the costs nobody budgeted for show up.

The last one is the one that surprises people most often: the datacenter gets switched off and months later somebody asks for a five-year-old backup, and there is no tape reader left. Before retiring anything, you have to decide whether the historical archive is migrated or kept readable, and that decision involves the legal team.

Migrating is not the goal: it is stopping paying to maintain what does not differentiate the business so you can spend on what does. With Barcelona switched off, here is what opens up for Contoso:

• Modernized billing: once stabilized on Managed Instance, refactor it towards App Service and get rid of the operating system.
• Analytics on data that used to be locked up: maintenance and billing data can flow into stlagocontosopro and be cross-referenced with bookings.
• Automation of processes that today depend on intervention in the datacenter.
• Real elasticity in season, which was one of the original motivations and until now only applied to the new platform.
• A second location without buying iron: the continuity that never existed.

And a final warning about ordering: the temptation to rearchitect during the migration is strong and is almost always a mistake. Move first, stabilize, and modernize afterwards with the system already in Azure and with real metrics. Whoever attempts both at once usually ends up with neither.

• Starting with the most critical workload. The learning happens in the pilot, not in billing.
• Migrating with no dependency inventory. It is what causes the "it worked and now it doesn't" of the following Monday.
• Rehosting everything and calling it transformation. You pay for the cloud without any of its advantages; if you rehost, do it with a modernization date.
• Promising immediate savings. During the migration you pay twice; management must know that from day one.
• Leaving governance until later. The landing zone comes before the first workload, always.
• Not defining rollback criteria. Without them, the decision gets taken tired, in the early hours, and badly.
• Forgetting to train the team. Without training, the new platform is operated with old habits.
• Neglecting the contract notice period. You can finish the migration and carry on paying for another year.
• Tip: retire the useless before migrating. It is the work with the best effort-to-benefit ratio in the project.
• Tip: measure and publish progress in workloads migrated and in remaining datacenter cost. An 18-month project needs visible wins.
• Tip: set budget aside for the overlap from the start; it is the most predictable extra cost and the one that goes down worst when it appears as a surprise.

Exercise 1. Assign a migration strategy — rehost, refactor, rearchitect, rebuild, replace or retire — to each of these five systems at a logistics company, justifying each choice and pointing out what information you are missing to decide with confidence: (a) a commercial ERP with official support on Azure; (b) an in-house .NET Framework web application with SQL Server; (c) an on-premises Exchange mail server; (d) a desktop application used by 8 people whose author abandoned it; (e) a reporting server nobody has opened in six months.

Exercise 2. Design the migration waves for that same company — 12 servers, 4 TB of data, accounting close on the 5th of every month, high season in November and December, a team of 3 systems people — over a 12-month timeframe. Define the pilot and why, the order of the waves, the windows to avoid and the success criteria for each one.

Exercise 3. The management of a mid-sized company asks: "will migrating to the cloud save us money?". Prepare the complete answer: what an honest TCO includes on both sides, why the saving does not appear in the first year, which benefits are not savings but are value, in which cases the correct answer is do not migrate, and what commitments you would ask management for before accepting the project.

Solution 1: (a) Commercial ERP with support on Azure: rehost, or refactor if the vendor offers a managed version; never touch its architecture, because you lose support. You need to know whether the license contract allows execution in a public cloud and whether the same vendor has a SaaS offering, in which case replacing might be better. (b) .NET Framework application with SQL Server: refactoring is the reasonable option — the database to Azure SQL Managed Instance, which supports features a single database does not, and the application to virtual machines or App Service with Hybrid Benefit; rearchitect only if elasticity is also needed and there is budget for testing. You need to know whether it uses local server components, MSMQ queues, scheduled tasks or hard-coded disk paths, which is what usually breaks the move. (c) On-premises Exchange: replace with Exchange Online; migrating mail servers to virtual machines is paying to carry on administering something that already exists as a service. You need to know mailbox volumes, retention requirements and whether there are integrations with internal applications. (d) Abandoned desktop application used by 8 people: the answer depends on the business, not the technology — if the process is dispensable, retire; if it is indispensable, replace it with a commercial alternative, and only as a last resort rehost it on a virtual desktop to buy time. You need to know what process it supports and whether an alternative exists on the market. (e) Reporting server unused for six months: a clear candidate to retire, but with the right procedure: a controlled shutdown with monitoring for a month before deleting, because a quarterly or annual report does not show up in a six-month window. You need to check actual accesses and ask finance.

Solution 2: wave 0, ready (months 1-2): landing zone, network and VPN, hybrid identity, training for the three-person team — which is the real bottleneck, and that is why training is part of the plan rather than an extra — and an inventory with dependency analysis. Pilot (month 3): a low-impact but representative system, for example the file server or a complete test environment; it teaches networking, permissions, data transfer and user experience without putting operations at risk, and it lets you measure how long the team really takes. Wave 1 (months 4-5): infrastructure servers — identity and shared services — because everything else depends on them. Wave 2 (months 6-7): non-critical supporting applications, grouped by dependency. Wave 3 (months 8-9): medium-risk data and business applications; the 4 TB are planned here, weighing the network against Data Box based on real bandwidth. Wave 4 (month 10): the accounting system, always avoiding days 1 to 8 of each month because of the close. Wave 5 (months 11-12, with the caveat below): decommissioning and closure. Forbidden windows: the whole of November and December because of high season — which in practice compresses the calendar and forces you to finish the critical work in October or push it to January — and the first days of each month. Success criteria per wave: applications reachable with equal or better measured performance, zero data loss verified by counts and checksums, incidents below an agreed threshold for two weeks, the source still available for 30 days and real cost within the estimate. A note of realism: three people cannot migrate and operate at the same time, so either the team is reinforced temporarily or the 12-month timeframe is optimistic.

Solution 3: an honest TCO on the on-premises side includes hosting, power and cooling, hardware depreciation and its planned renewal, virtualization and system licenses, staff dedicated to maintaining infrastructure — the most frequently forgotten — support and contracts, connectivity, backups and their custody, insurance and, if you want to be rigorous, the opportunity cost of the tied-up capital and the risk of having no second site. On the Azure side: compute, storage and network consumption, data transfer out, transferred or new licenses, migration tooling, training, project hours, consultancy, the overlap during the transition and the ongoing operational cost of the new model. Why there is no saving in the first year: because you pay for both infrastructures at once, because the project has a significant one-off cost and because the freshly migrated workloads are unoptimized — the real saving arrives with the later right-sizing, reservations and modernization. Benefits that are not savings but are value: elasticity for peaks that used to be lost sales, provisioning time going from weeks to minutes, business continuity without buying a second datacenter, the ability to experiment at marginal cost, services you cannot build in-house — AI, analytics — enterprise-grade security and compliance tooling, and freeing the team from tasks that do not differentiate the business. When the correct answer is do not migrate: when the hardware has just been bought and is not depreciated, when there is a legal residency or sovereignty constraint that cannot be satisfied, when the workload is constant and predictable for years and comes out cheaper on-premises, when there is an insurmountable physical dependency, when the organization does not have and cannot acquire the skills, or when the critical application is an unsupported binary nobody knows how to rebuild. Commitments I would ask management for: an executive sponsor with the authority to decide, explicit budget for the overlap and for training, written acceptance that the return arrives in the second year, real dedication from the project's people — not squeezed in between incidents — and the authority to retire systems and to say no to migrations that make no sense.

You now know that migrating is not moving machines: it is an organizational change with a technical component. You know the Cloud Adoption Framework and its phases — strategy, plan, ready, adopt with migration and innovation, govern and manage — with the two things that are most often forgotten: that govern and manage are cross-cutting and not final phases, and that adopting includes innovating, not just relocating the old.

You know how to build the business case starting from ranked motivations — the expiring contract, the hardware renewal, the seasonal peaks, agility, the support being withdrawn, the non-existent continuity — and from a complete TCO: Barcelona's €340,000/year against ≈€205,000 in steady state plus ≈€120,000 of project, with the honest message that the return arrives in the second year because during the migration you pay twice. You know how to do the inventory with Azure Migrate — discovery, assessment, dependencies and migration — and why dependencies are what reveal the surprises: 34 servers where 26 were documented, five with no owner and two of those carrying traffic.

You can handle the six strategies with their effort, risk and benefit, and the reasoned assignment of each Contoso system, including the two columns that improve any plan: what gets retired and what stays. You understand what a landing zone is, what it solves, its conceptual architecture and the fact that the mg-contoso hierarchy with its governance initiative, the hub and the single log workspace are already an embryonic landing zone. You know how to organize waves with a pilot chosen for its ability to teach, an 18-month calendar that respects closes and high season, and success criteria; how to choose the data migration route — Database Migration Service, backup and restore, Data Box for the 12 TB, file sync or replication — with the pattern of initial load, replication, parallel validation and short cutover; and how to execute the cutover window with its decision point at a fixed time and its rollback prepared in writing.

And you know what is almost never in the plans: change management — who operates what afterwards, the platform, FinOps and SRE roles, and internal resistance as a real risk managed by training before migrating and giving ownership of the new environment to whoever administered the old — datacenter decommissioning with its hidden costs — overlap, notice period, certified erasure, licenses with minimum terms, restoring the premises and the tapes that outlive the reader — and what gets innovated afterwards, with the golden rule: move first, stabilize, modernize later.

With this, Contoso Airlines has its new platform built and the route mapped out for what is left in Barcelona. One last lesson remains, and it looks forwards rather than back: where Azure is heading — AI built into everything, platform engineering, serverless by default, distributed cloud, sustainability, zero trust and European regulation — how to keep up without drowning, and the complete map of certifications with the one that matches your profile and what you still need before sitting it after this course.