The Model Is the Easy Bit

This is the first stage of a connected journey. We begin with the inherited estate, because every decision that follows depends on understanding what is really holding delivery back.

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.

The model that was ready but could not go live

Consider a composite UK insurer. Its pricing team has spent months developing a new model. The evaluation looks strong. The business sponsor wants the benefit in the next release. A successful experiment has been registered, documented and presented.

Then production preparation begins.

The runtime identity cannot read one of the required source tables. Nobody can say with confidence whether the training dataset applies the same exclusions as the scheduled production feed. A package used in development is incompatible with the approved production runtime. The shared compute policy cannot support one part of the workload, but the exception route is unclear. The governance submission links to results from a different model version. The output format does not match what the downstream pricing system can consume. Monitoring has been discussed, but thresholds, alert recipients and rollback authority have not been agreed.

Each issue looks small when viewed alone. Together they reveal something much larger. The organisation has built a model, but it has not yet built the capability required to turn that model into a reliable insurance decision.

The model was ready. The organisation was not.

Why the visible problem is rarely the real problem

An enterprise machine-learning framework is often described as a collection of templates for training, registering and deploying models. That description is attractive because it makes the problem look bounded. Build the repository, create the pipeline, choose the platform and delivery should accelerate.

Insurance exposes the weakness in that view. Models sit inside a web of customer data, financial decisions, regulatory expectations, legacy systems and operational processes. A technically elegant model can still fail because its wider delivery system is fragile.

The model is downstream of seven connected capabilities.

Legacy data and lineage determine whether the inputs are explainable. Identity and access determine whether people, pipelines and serving workloads can reach those inputs safely. Compute, runtimes and packages determine whether an experiment can be reproduced. Environment and deployment parity determine whether the same code behaves consistently as it moves towards production. Governance evidence determines whether the version being approved is the version being deployed. Downstream integration determines whether the model can influence a real insurance process. Monitoring and ownership determine whether anyone will notice when the service or the model deteriorates.

This is why a failed production release is rarely just an access problem, a package problem or a governance problem. It is usually evidence that the delivery path was designed too late.

---

Eight ways a legacy-to-AI transformation can fail

These failure states are connected. One unresolved weakness creates the conditions for the next.

1. The expensive legacy replica

The organisation moves servers, pipelines and reports but leaves ownership, duplication and manual controls unchanged. Cloud services add flexibility, but the same brittle dependencies now run on a different bill. Costs become more visible without becoming more intentional.

The warning sign is a migration programme measured by assets moved rather than capabilities improved or legacy services retired.

2. The data-swamp outcome

Teams copy data into cloud storage faster than they define contracts, owners, quality thresholds and approved uses. More data becomes technically available, yet analysts and model teams still create their own reconciliations because they do not trust the shared version.

The result is not a single source of truth. It is a larger set of competing truths.

3. The platform turf war

Microsoft Fabric and Databricks are introduced as rival destinations. Teams duplicate datasets and pipelines so that each platform can claim completeness. Architecture decisions become vendor debates rather than workload decisions.

That is unnecessary. Fabric uses OneLake as a logical data foundation, and current interoperability allows supported OneLake data to be queried from Azure Databricks through read-only catalog federation. Fabric can also expose supported Unity Catalog data through metadata mirroring and shortcuts without replicating the underlying data. The details and limitations matter, and Parts 7 and 8 will examine them carefully. The leadership point is simpler: one governed estate can use more than one engine without becoming two disconnected estates.

References: Microsoft Fabric overview, OneLake catalog federation, Unity Catalog mirroring.

4. The security backlash

Least privilege is correct, particularly where pricing, claims, fraud or customer data is involved. Trouble begins when access is designed after development. Missing permissions are then experienced as arbitrary blockers, urgent exceptions multiply and teams look for unofficial routes.

Good security is not weaker control. It is a delivery design in which human, pipeline and runtime identities are known before the build depends on them.

5. The permanent pilot

Experimentation remains productive because individuals can work around uncertainty. Production does not. Models accumulate in notebooks and demonstrations while the path through access, packages, testing, promotion, evidence and support remains bespoke.

The organisation appears innovative but captures little repeatable value. Every successful prototype increases the future handover backlog.

6. The governance bottleneck

Governance is invited after model development and asked to approve a package assembled manually. Metrics come from one run, data documentation from another and deployment configuration from a third. Review becomes slow because evidence is inconsistent, not because governance is inherently slow.

The better goal is evidence by design. Version, commit, data references, features, parameters, tests, approval and deployment history should emerge from the delivery path. Human judgement remains essential, but evidence collection should not rely on archaeology.

7. The hero dependency

As the platform grows, users discover who knows how to fix access, restart compute, approve a package, interpret a deployment error or find the correct owner. That expert becomes the routing layer for the entire capability.

Heroic support feels helpful in the short term. At scale it is an operational risk. Knowledge must become service routes, request forms, runbooks, dashboards and visible ownership.

8. The silent production failure

A scheduled job can complete while its inputs drift, its predictions change materially or its business performance declines. Technical availability is not model health. Without quality checks, statistical monitoring, thresholds, alert routing and rollback authority, a production model can remain online after it has stopped being dependable.

This is the final consequence of treating deployment as the finish line.

---

The cloud is an opportunity to redesign the path

None of this is an argument against cloud migration. It is an argument for using migration to remove accumulated operating debt.

Microsoft documents routes for moving and modernising legacy, on-premises and PaaS workloads in Fabric. Fabric Data Factory can connect to supported on-premises sources through an on-premises data gateway, which makes phased coexistence possible while teams validate, reconcile and retire workloads deliberately. See the Fabric migration overview and on-premises data access.

The important choice is not simply how to copy data. It is what the new path should make repeatable:

• Clear ownership before movement
• Reconciliation before cutover
• Governed identity before development depends on access
• Reproducible environments before production promotion
• Evidence linked to the model version
• Downstream consumption designed with the model
• Monitoring and rollback agreed before release
• Official support routes before adoption scales

The journey produces a system, not a collection of projects

This series will build one artefact at each stage. Each output becomes the input to the next article.

The sequence is deliberate:

This is a capability sequence, not a requirement to replace one vendor with another. The platforms provide tools. The organisation must provide coherent ownership, standards, controls and operating decisions.

---

A transformation risk diagnostic

Use this diagnostic before treating platform selection as the main decision.

If several warning signs are familiar, the organisation does not need to abandon its transformation. It needs to widen its definition of transformation.

What comes next

At the end of Part 1, our insurance company has not migrated a pipeline or created a lakehouse. It has achieved something more important: it can see that its problem is architectural and organisational, not merely technical.

The transformation risk and dependency map is now the first artefact in the journey. It shows where ownership is unclear, where handovers are fragile and where a platform decision would otherwise conceal unresolved risk.

The answer is not to select another platform and start moving data. The next task is to decide what should be preserved, what should be retired, what must be redesigned and who will own the decisions.

---

Sources and claim map

This article draws on four classes of evidence. Internal evidence covers recurring delivery patterns and controls from Athos engagement standards. Official capability covers current product and migration facts supported by primary vendor documentation. Athos recommendation covers architectural and operating-model conclusions drawn from that evidence. Composite narrative describes a realistic insurer scenario used to explain a connected problem; it is illustrative and does not disclose any single organisation's internal details.

Claim	Class	Source
Access, compute, package and environment mismatches block model delivery	Internal evidence	Athos environment, identity and access standards; package and runtime governance standards
Late notebook handovers create repeated MLOps refactoring	Internal evidence	Athos model factory, repository and PR governance standards
Governance assembled after development is slow and inconsistent	Internal evidence	Athos model card, governance submission and metadata-driven MLOps standards
Monitoring requires data, prediction, performance, alert and rollback controls	Internal evidence	Athos model monitoring and AI operations standard
Routine delivery should use service routes and runbooks rather than named experts	Internal evidence	Athos service catalogue, onboarding and release standards
Fabric provides a unified analytics platform and documented migration routes	Official capability	Microsoft Fabric migration overview
Fabric can access supported on-premises sources through an on-premises data gateway	Official capability	Access on-premises data in Fabric Data Factory
Supported OneLake data can be queried from Azure Databricks through catalog federation	Official capability	Enable OneLake catalog federation
Fabric can expose supported Unity Catalog data through metadata mirroring and shortcuts	Official capability	Mirroring Azure Databricks Unity Catalog
A model is only as reliable as the delivery system beneath it	Athos recommendation	Synthesis of internal capability and operating-model evidence
The eight failure states form a causal chain	Athos recommendation	Synthesis of migration, governance, delivery and operations patterns
The model that could not go live	Composite narrative	Constructed from recurring pain points across Athos engagements

Product-claim boundaries. This article does not claim unrestricted bidirectional Fabric and Databricks writes, universal zero-copy interoperability or automatic governance. Later articles state supported item types, read-only boundaries, identity requirements and preview status where material. Vendor capabilities change; product claims were checked against official documentation at the time of writing.

← Back to Blog