Build a Bridge, Not a Big Bang

Part 2 gave our insurance company a capability charter. Policy-to-claims reporting now has a measurable outcome, a dependency group, accountable owners, a preserve, retire or redesign decision, evidence expectations and an exit condition.

That clarity creates momentum. It also creates a new risk.

The executive programme proposes one migration weekend. Shut down the old reporting path on Friday, move the data, redirect users and begin Monday in the cloud. A single date feels decisive. It gives the board a milestone, procurement a deadline and every team a shared focus.

It also compresses every unknown dependency, untested control and recovery decision into the same few hours.

The safer alternative is not a slow migration without accountability. It is a bridge: a sequence of controlled waves in which every span proves something, every gate has an owner and the coexistence period has an expiry condition.

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.

A deadline is not a migration sequence

The insurer's loss-ratio report looks like one reporting workload. Its dependency group says otherwise.

Policy records arrive from a legacy SQL platform. Claims movements arrive throughout the day. Finance supplies reference rates and control totals. Scheduled integration jobs assemble the reporting state. Manual reconciliations explain late claims and corrections. Power BI reports serve pricing, claims and finance teams. Identity groups, service accounts, business calendars and named experts hold the route together.

Moving the visible report first would create a cloud front end over an unproven chain. Moving every component together would maximise the number of things that can fail at once.

Wave planning changes the unit of progress. The programme no longer asks, "How many servers have moved?" It asks, "What evidence has this dependency group produced, and what uncertainty has been removed?"

Microsoft's migration guidance recommends grouping workloads by dependency, minimising the time a workload is split across environments, aligning waves with business events, defining downtime expectations and testing rollback. It also recommends starting with simpler workloads while ensuring early waves are representative enough to expose real complexity. See Plan your migration.

For the insurer, an early wave cannot be a convenient spreadsheet that proves only that files can be uploaded. It must exercise the real route: on-premises connectivity, identity, policy and claims data shapes, incremental change, reconciliation, monitoring and business acceptance.

Coexistence is an architecture, not a delay

Leaders often hear "coexistence" and imagine duplicated cost, prolonged risk and a programme afraid to commit. Those outcomes are real when the transition has no boundaries.

Designed coexistence is different. It declares:

• Which system is the source of record for each domain.
• Where write authority sits during every wave.
• Which legacy and cloud read paths are permitted.
• How changes reach the target and how lag is measured.
• Which controls compare the two environments.
• Who supports the mixed service.
• What evidence permits cutover or triggers rollback.
• When the temporary bridge must be removed.

The insurer adopts one firm rule: one operational write authority for each data domain in each wave. Policy and claims systems remain authoritative while Fabric proves the analytical path. Reports may run in both environments, but teams do not casually update both sides and hope to reconcile conflicting truth later.

Coexistence becomes a managed state with an entry condition, operating model and exit condition. Without all three, a pilot can become permanent architecture by accident.

---

Build the migration in waves

The capability charter is converted into a Migration-Wave and Coexistence Plan.

Wave 0: Prove the route

Wave 0 moves no production consumer. It proves the bridge can carry weight.

The team deploys and secures the on-premises connection, tests representative policy and claims volumes, measures throughput, confirms firewall and identity behaviour, captures failure telemetry and rehearses recovery. Fabric's on-premises data gateway provides connectivity between local sources and supported Data Factory workloads, but the gateway itself does not decide what should move or how truth will be maintained. See Access on-premises data in Data Factory for Microsoft Fabric.

The exit evidence includes successful connectivity, repeatable deployment, an agreed performance baseline, monitored failure states and a named platform owner. If the route cannot be restored without one specialist, it is not ready for Wave 1.

Wave 1: Establish a trusted first copy

The team begins with stable reference data and a bounded policy snapshot. This is not because policy data is unimportant. It is because a defined initial state makes mapping, schema, access, reload and reconciliation behaviour observable before high-frequency claims changes are introduced.

A full copy may be appropriate for the first load. The team also designs what happens when it must be repeated. Resetting or replaying a load without considering append, merge or overwrite behaviour can create duplicates or replace data unexpectedly. Fabric Copy job distinguishes full and incremental modes and maintains incremental state from the last successful run. See Incremental copy in Copy job.

Wave 1 exits when counts, hashes, schema, security classification, freshness and selected policy totals agree, and when the data owner approves the target for controlled analytical reading.

Wave 2: Align changing claims data

Claims movements expose the decisions a static copy can hide. Records arrive late. Existing claims change. Some records may be removed or corrected. The target must represent the business requirement, not merely whatever the easiest connector happens to deliver.

The team chooses the movement pattern from change behaviour.

A reliable watermark can support incremental copying when a column advances for every relevant insert or update. It does not detect rows deleted at the source. If delete propagation matters, the design needs another pattern or an explicit compensating control. See Incremental copy in Copy job.

Change data capture can propagate inserts, updates and deletes when CDC is enabled on a supported source and supported by the connector. That qualification matters. "Use CDC" is not an implementable decision until source configuration, connector capability, keys, write behaviour, retention and recovery are verified. See Change data capture in Copy job.

Mirroring may suit a supported near real-time analytical replica. It is not a promise of zero latency or zero operational dependency. Microsoft notes that latency can vary with region, change volume, network conditions and the compute allocated to an on-premises gateway. See Mirroring in Microsoft Fabric.

A Data Factory pipeline becomes useful when movement needs dependencies, transformation, retries, control steps or downstream orchestration. Copy activity can move data between supported stores and sit inside a wider pipeline whose later activities transform or validate it. See Copy activity in Data Factory for Microsoft Fabric.

The result is not one pattern for the entire estate. Reference data may use a repeatable full load, policy data a reliable incremental route and changing claims a supported CDC or mirroring pattern. Each choice records why it is safe and how failure is detected.

Wave 3: Operate both read paths deliberately

The cloud report now runs beside the legacy report for a bounded acceptance period. The source systems remain authoritative. Fabric serves candidate analytical outputs. Exceptions are logged and replayed through an owned process. Support teams monitor freshness, gateway health, movement failures, reconciliation thresholds and user access.

This architecture prevents a common error: validating only what the user sees. A polished dashboard can conceal missing deletes, stale reference data, duplicated rows or incorrect financial meaning. The reconciliation lane is independent of presentation and tests several layers:

• Structural checks for schema, partitions, keys and expected files.
• Volume checks for counts, completeness and arrival windows.
• Integrity checks using hashes or checksums where appropriate.
• Business controls such as claim counts, incurred values, earned premium and loss-ratio tolerances.
• End-to-end scenarios for late claims, reopened claims, policy corrections and period close.
• Exception aging, ownership and replay.

Row counts are useful, but equal counts do not prove equal meaning.

---

Cut over through evidence, not optimism

The insurer schedules cutover around the reporting calendar, not merely around engineering availability. It defines a data freeze or final-delta procedure, user communications, monitoring thresholds, rollback triggers and the person authorised to make each decision.

The cutover record answers five questions:

1. Is the route healthy under expected load and recoverable after failure?
2. Does the target contain the right data, not only the expected number of rows?
3. Do business totals and critical policy-to-claims scenarios agree within approved thresholds?
4. Can operations monitor, support and restore the service without the delivery team standing beside them?
5. Can the organisation return to a known state before unacceptable harm occurs?

Microsoft's execution guidance recommends integrity checks beyond row counts, including checksums or hashes, end-to-end functional testing, application-owner confirmation and retention of the source as a temporary fallback during stabilisation. See Execute migration to cloud.

Rollback is therefore a designed transition, not a sentence in a meeting pack. The plan names the trigger, authority, last consistent data state, traffic or report-routing change, communications route and maximum decision time. It is rehearsed before the production window.

After a successful cutover, the team monitors user access, freshness, failures, reconciliation exceptions and performance through the agreed stabilisation period. The bridge remains available only as long as the fallback is useful and controlled. Then decommission authority closes data-retention, records, security, support, licence and cost obligations before the legacy read path is removed.

The reusable migration artefact

For every dependency group, the Migration-Wave and Coexistence Plan records:

This artefact prevents migration status from collapsing into percentages. "Eighty per cent migrated" says little about whether the remaining twenty per cent contains the finance control, identity dependency or rollback path that determines safety.

What comes next

The insurer can now connect the inherited estate to a cloud analytical capability without betting the reporting service on one untested leap. The capability charter has become a wave plan. Movement patterns follow data behaviour. Coexistence has one operational truth, an independent evidence lane and an expiry condition. Cutover and rollback have named authorities.

But a bridge only controls how capabilities arrive. It does not decide where capacities, domains, workspaces, identities, environments and deployment boundaries should sit once they reach Microsoft Fabric.

If every delivery team lands data differently, the bridge will carry the old disorder into a newer platform.

---

Sources and claim map

This article draws on four classes of evidence. Internal evidence covers recurring migration, release, validation, rollback, operating-model and decommission patterns from Athos engagement standards. Official guidance covers current Microsoft migration and Microsoft Fabric documentation. Athos recommendation covers the Migration-Wave and Coexistence Plan, the evidence-gate structure, the singular write-authority rule and bridge-expiry discipline. Composite narrative describes the insurer's policy-to-claims dependency group and proposed single migration date; it is illustrative and does not disclose any single organisation's internal details.

Claim	Class	Source
Capability scope, ownership and measurable outcomes frame wave entry criteria	Internal evidence	Athos capability charter and step-by-step capability standards
Release evidence, controlled rollback and decommissioning govern cutover and retirement	Internal evidence	Athos continuous improvement, release and decommission standard
Data quality, test evidence and operational controls drive reconciliation layers	Internal evidence	Athos AI governance and model risk tiering standard
Durable decisions, exceptions and approvals support go or no-go authority	Internal evidence	Athos information architecture and decision-log standards
Migration waves should group dependent workloads, minimise time split across environments, consider business calendars, define downtime and test rollback	Official guidance	Plan your migration
An on-premises data gateway provides secure connectivity from local sources to Fabric Data Factory workloads	Official guidance	Access on-premises data in Data Factory for Microsoft Fabric
Copy activity moves data between supported stores and can participate in pipelines with later transformation and monitoring steps	Official guidance	Copy activity in Data Factory for Microsoft Fabric
Copy job supports full and incremental copy and resumes incremental state from the last successful run	Official guidance	Incremental copy in Copy job
Watermark-based incremental copy needs a reliable changing column and does not detect source deletes	Official guidance	Incremental copy in Copy job
CDC-based Copy job can propagate inserts, updates and deletes when source CDC is enabled and the connector supports it	Official guidance	Change data capture in Copy job
Fabric mirroring can replicate supported database sources into OneLake, while latency depends on factors including region, change volume, network and gateway compute	Official guidance	Mirroring in Microsoft Fabric
Cutover validation should go beyond row counts to checksums, functional testing and owner acceptance, with the source retained temporarily as a fallback	Official guidance	Execute migration to cloud
Coexistence is a designed and expiring architecture state with one write authority per domain	Athos recommendation	Synthesis of the migration, release and operating-model evidence
The insurer's policy-to-claims dependency group and single migration date	Composite narrative	Constructed from recurring patterns across Athos engagements

Scope boundary. Part 3 establishes migration waves, movement-pattern selection, hybrid coexistence, reconciliation, cutover and rollback. Part 4 defines Fabric tenant, capacity, domain, workspace, identity and deployment boundaries; Part 3 does not design the Fabric landing zone. Vendor capabilities change; product claims were checked against official documentation at the time of writing.

← Previous: Part 2, Do Not Migrate the Mess   ·   Back to Blog