Part 1 gave our insurance company a transformation risk and dependency map. It made the hidden problem visible: the production model was not blocked by one piece of technology. It was blocked by a delivery system in which data, identity, runtime, governance, integration and ownership had never been designed to work together.
That map changes the next conversation. The question is no longer, "Which platform should we buy?" It is, "What should this estate become, and who has authority to decide?"
The sequence begins by making inherited risk visible. It then establishes ownership and migration discipline before introducing Microsoft Fabric, OneLake, deliberate Databricks workload placement, model delivery, governance automation and AI operations. Fabric and Databricks are not presented as consecutive platform replacements: the target is one governed estate in which each engine has a deliberate role and unnecessary data copying is avoided.
About this series: From Legacy to Intelligent
The journey from legacy infrastructure to AI is not a sequence of technology purchases. It is the gradual construction of a governed operating system for data and AI. Every stage removes one fragile handover and replaces it with a reusable, governed capability.
Each article leaves one reusable artefact for the next. Later parts publish in sequence.
- Recognise — The Model Is the Easy Bit
- Organise — Do Not Migrate the MessYou are here
- Connect — Build a Bridge, Not a Big Bang
- Establish — Fabric Is the Landing Zone, Not the Strategy
- Unify — OneLake Is Not One Giant Bucket
- Trust — Turn Migrated Data into Data Products
- Choose — When Databricks Earns Its Place
- Interoperate — One Estate, Two Engines
- Industrialise — Replace Model Projects with a Model Factory
- Evidence — Generate Governance, Do Not Assemble It
- Operate — AI Is a Production Service
- Compound — Make Every Use Case Improve the Capability
The workshop where every definition of success was different
The insurer brings finance, technology, data, security, risk, operations and business leaders into a migration-planning workshop. The opening instruction sounds decisive: move the legacy data estate into the cloud within two years.
Within twenty minutes, the simplicity disappears.
Finance expects datacentre cost and licence exposure to fall. Technology wants unsupported servers and brittle integration removed. The data team wants fewer copies and a trusted foundation for analytics. Business teams want their pricing, claims and finance outputs to keep arriving without disruption. Security wants human and workload identities designed before access is granted. Risk wants control evidence to remain intact. Operations wants to know who will support the mixed estate during transition.
All of these outcomes are reasonable. They are not the same outcome.
The existing inventory does not settle the disagreement. It lists servers, databases, packages, reports and jobs, but it does not explain which business decisions they support, which items duplicate each other, which manual reconciliations are actually controls, or which named expert is quietly holding the process together.
An inventory says what exists. A migration plan must say what should happen to it and why.
Start with outcomes, not target services
A platform-led programme often begins by matching source technologies to target services. That work is necessary, but it comes too early if the organisation has not agreed what value the migration should create.
For this insurer, "move the policy data warehouse" is an activity. Better outcomes are measurable:
- Remove two overnight reconciliations without weakening financial control.
- Reduce the time required to provide an approved pricing dataset from ten days to one.
- Retire three duplicated reporting stores after consumers accept a governed replacement.
- Make data lineage and ownership visible for every production model input.
- Restore a critical reporting service within its agreed recovery objective without relying on one specialist.
These outcomes change architecture decisions. A stable workload with no near-term modernisation need may justify retention or a low-change move. A duplicated report may deserve retirement. A brittle pipeline that prevents trusted reuse may need redesign rather than relocation.
Microsoft's Cloud Adoption Framework makes the same underlying distinction: business drivers should determine whether a workload is retired, retained, rehosted, replatformed, refactored, rearchitected, replaced or rebuilt. It also warns that rehosting a problematic workload carries its existing technical debt forward. See Select a cloud migration strategy.
The platform provides options. The organisation must choose the outcome.
Organise dependency groups, not isolated assets
The next mistake is treating each inventory row as an independent migration unit.
The insurer's monthly loss-ratio report appears to be a Power BI artefact. In reality, it depends on a SQL extract, a scheduled package, a shared file, a spreadsheet adjustment, a finance reconciliation, an Entra group, a reporting calendar and an operations contact. Moving only the visible report does not move the capability.
A more useful unit is the dependency group: the systems, data, reports, jobs, identities and controls that contribute to one business outcome.
For each group, the team records:
- The business decision or service it supports.
- The accountable business and technical owners.
- Upstream sources and downstream consumers.
- Critical jobs, files, interfaces, identities and manual controls.
- Data sensitivity, criticality and regulatory obligations.
- Tolerated downtime and recovery expectations.
- Known constraints, unsupported components and named-expert dependencies.
Microsoft's migration-planning guidance recommends grouping workloads by shared databases, APIs, authentication services and network connections. It also calls for owners, criticality, migration methods, downtime, rollback authority and success criteria to be documented. See Plan your migration.
This is not paperwork around the migration. It is the information required to avoid cutting through a hidden dependency during it.
Preserve, retire or redesign
Leaders need a decision frame that is simpler than a catalogue of technical methods but still leads to a credible implementation choice. For each dependency group, ask whether to preserve, retire or redesign.
Preserve means the capability remains necessary and is sufficiently sound. It may stay where it is for now, move with minimal change, or move onto a managed service. Preserve does not automatically mean migrate.
Retire means the capability, duplicate, report, job, reconciliation or platform component is no longer justified. Retirement is not deletion by enthusiasm. The team must confirm consumers, dependencies, records obligations, evidence retention and decommission authority.
Redesign means the current capability cannot meet the intended outcome safely, economically or repeatedly. It may require code refactoring, architectural change, replacement with a managed product, or a rebuild around a different process.
The distinction prevents two common errors. The first is redesigning everything before any value can move. The second is copying everything and promising to modernise later. A dependency group can be preserved temporarily while a replacement is built, provided the coexistence period, owner and exit condition are explicit.
Fabric has documented migration paths for legacy, on-premises and PaaS platforms, including several Microsoft analytics sources. Those routes are useful once the organisation has chosen the right outcome for each group. They do not make the rationalisation decision on its behalf. See the Microsoft Fabric migration overview.
Decision rights turn alignment into delivery
Even a strong classification stalls when everybody can advise and nobody can decide.
Our insurer initially sends every migration question to one steering committee. The agenda grows faster than decisions are made. Technical teams wait for business priorities. Business owners wait for cost estimates. Security is invited after designs depend on access. Operations is asked to accept support after cutover dates are announced.
The answer is not a larger meeting. It is explicit decision rights.
The business capability owner is accountable for outcome and priority. The data owner decides acceptable quality, use and stewardship. Architecture owns the technical strategy within agreed standards. Security owns identity and control requirements. Risk interprets regulatory and model-risk obligations. Finance validates the benefit case. The service owner holds go or no-go and rollback authority. The same service owner approves decommission after data, records, operational and financial evidence is complete.
A RACI table can help describe participation, but it is not enough. The operating model also needs decision forums, response times, named backups, escalation routes and a visible log. Otherwise accountability still disappears when a deadline is close or one person is unavailable.
Microsoft's Fabric governance guidance recommends defining roles, approval and veto authority, issue management and valid exception processes. It also argues for iterative, proportionate governance that supports productive work. See Fabric adoption roadmap: Governance.
This matters in insurance because control and enablement cannot be separated. If governance arrives only to block, teams create workarounds. If delivery proceeds without authority, the programme creates unowned risk.
The migration principles that prevent backsliding
The insurer now agrees a small set of principles that every dependency group must satisfy:
- Every move serves a named business outcome.
- Every dependency group has an accountable business owner and technical owner.
- No workload enters wave planning without a preserve, retire or redesign decision.
- Data ownership, identity and control obligations are known before build.
- A copied asset is not complete until consumers, reconciliation and operations are ready.
- Every temporary coexistence arrangement has an owner and expiry condition.
- Exceptions record rationale, risk, compensating control, approver and review date.
- Legacy retirement is measured as carefully as cloud creation.
These principles are intentionally technology-independent. They remain valid whether the next implementation uses Fabric Data Factory, a gateway, a copy process, change data capture, mirroring or another supported pattern. Those choices belong to the next stage.
The capability charter
The output of Part 2 is not a hundred-page strategy. It is a concise capability charter that keeps decisions connected.
The charter records the outcome, scope and exclusions; the preserve, retire and redesign principles; the named decision authorities; the dependency-group record; evidence and control expectations; the exception route; benefit measures; entry criteria for wave planning; and exit or retirement conditions.
It is useful only if teams use it to make real choices. A ceremonial charter that approves every workload and names no decommission authority simply gives the mess a cover page.
Microsoft's Fabric adoption guidance links successful analytics adoption to business alignment, structured planning and transparent governance decisions. It cautions that poorly aligned governance can encourage workarounds rather than compliance. See Fabric adoption roadmap: Business alignment.
A readiness checklist for wave planning
Before a dependency group can enter Part 3's migration-wave plan, the insurer asks:
If several answers are unclear, adding the group to a wave would convert uncertainty into delivery pressure. The right response is not endless analysis. It is a time-boxed decision with named authority and visible evidence.
What comes next
The insurer can now explain what the migration is meant to improve. It has organised the estate into dependency groups, decided what to preserve, retire or redesign, and named who can approve priority, strategy, release, rollback and decommission.
It still cannot move those groups safely. Some legacy components must coexist with new cloud services. Data will need controlled movement and reconciliation. Cutovers must respect business calendars and recovery tolerances. The programme needs waves that create learning without turning the first pilot into a permanent exception.
The capability charter is now the second artefact in the journey. The next task is to translate it into a migration-wave and coexistence plan.
Next in the series · Part 3, ConnectTranslating the capability charter into controlled migration waves - selected movement patterns, one write authority, an independent evidence lane, and a coexistence window with a designed exit.
Read Part 3 →Sources and claim map
This article draws on four classes of evidence. Internal evidence covers recurring capability, ownership, decision-log and decommission patterns from Athos engagement standards. Official guidance covers current migration, adoption and governance guidance from Microsoft Learn. Athos recommendation covers the preserve, retire or redesign frame, the capability charter structure and the decision-rights operating model. Composite narrative describes the insurer's planning workshop and estate examples; it is illustrative and does not disclose any single organisation's internal details.
| Claim | Class | Source |
|---|---|---|
| Capability outcomes, sponsorship, scope and measures frame the charter | Internal evidence | Athos capability charter and step-by-step capability standards |
| Copying an unorganised estate retains operating debt | Internal evidence | Athos delivery pain-point, access and ownership patterns |
| Decision records, approvals and durable documentation support authority | Internal evidence | Athos information architecture and decision-log standards |
| Controlled retirement requires exit evidence | Internal evidence | Athos continuous improvement, release and decommission standard |
| Risk participation and proportionate evidence scale with criticality | Internal evidence | Athos AI governance and model risk tiering standard |
| Fabric documents migration routes for legacy, on-premises, PaaS and several Microsoft analytics sources | Official guidance | Microsoft Fabric migration overview |
| Workloads can be retired, retained, rehosted, replatformed, refactored, rearchitected, rebuilt or replaced according to business drivers | Official guidance | Select a cloud migration strategy |
| Rehosting a problematic workload carries technical debt forward and can create later rework | Official guidance | Select a cloud migration strategy |
| Migration plans should group related dependencies and document owners, criticality, methods, downtime, rollback authority and success criteria | Official guidance | Plan your migration |
| Governance is most effective when iterative, proportionate and aligned with business outcomes; roles, authority, policies and exceptions should be explicit | Official guidance | Fabric adoption roadmap: Governance |
| Data and analytics initiatives should stay aligned with business strategy through structured, iterative planning | Official guidance | Fabric adoption roadmap: Business alignment |
| Preserve, retire or redesign as a leadership decision before technical strategy | Athos recommendation | Synthesis of the migration, governance and operating-model evidence |
| The insurer's planning workshop and estate examples | Composite narrative | Constructed from recurring patterns across Athos engagements |
Scope boundary. Part 2 establishes intent and authority. Part 3 covers migration-wave sequencing, hybrid coexistence, gateways, copy, change data capture, mirroring, reconciliation, cutover and rollback mechanics. Vendor capabilities change; product claims were checked against official documentation at the time of writing.
About to migrate an estate nobody has organised yet?
We help organisations decide what to preserve, retire and redesign before the first workload moves - dependency groups, named decision rights, evidence expectations and exit conditions - then build the governed Fabric and Databricks estate that follows. Book a free 30-minute call to talk through your own estate.
← Previous: Part 1, The Model Is the Easy Bit · Back to Blog · Next: Part 3 →