Migrate Microsoft Fabric Ontologies Before the January 2027 Retirement Without Breaking AI and Operations

Executive summary

Microsoft has set **January 3 1 , 2027** as the retirement date for the old Microsoft Fabric ontology experience. Existing items do not transform in place. Fabric creates a separate ontology in the new experience, copies only supported definitions, and leaves the original available until retirement. Teams must then reconnect downstream consumers and recreate behavior that the copy does not carry forward, including rules and Activator alerts.1

That makes this more than an item-conversion exercise. An ontology supplies business meaning to agents, dashboards, and operational workflows. A migration can appear technically successful while changing the meaning of a relationship, dropping a rule, breaking a consumer, widening access, increasing capacity use, or producing different answers to the same business question.

The enterprise response should be a controlled semantic cutover:

1. Inventory every old ontology and its consumers.
2. Baseline definitions, permissions, representative questions, alerts, and capacity behavior.
3. Remove migration blockers and create a new-experience copy in a non-production path.
4. Rebuild omitted behavior and reconnect each consumer explicitly.
5. Compare old and new results under production security personas.
6. Cut over in waves, observe, and retain a time-bounded rollback path before retirement.

The objective is not merely to recreate an item. It is to preserve a dependable contract between enterprise data, business vocabulary, AI reasoning, and operational action.

The enterprise problem: semantic infrastructure now has a deadline

An ontology describes the business in concepts such as Customer, Asset, Order, Location, or Case, along with their properties, relationships, rules, and data bindings. In the new Fabric experience, it can also organize concepts with namespaces, retain metrics sourced from Power BI semantic models, and provide common context to supported agents and other consumers. 2

When an ontology is experimental, replacing it may be straightforward. When it has become shared infrastructure, the dependencies are less obvious:

• A Fabric data agent may use it to interpret natural-language questions.
• An operations agent may monitor concepts and relationships.
• A Real-Time Dashboard may depend on its definitions.
• Activator alerts may turn a rule into an operational notification.
• Teams may query or manage it through an API.
• Security depends on both ontology permissions and access to the bound sources.
• Graph refreshes and AI queries consume Fabric capacity.

Microsoft's copy flow preserves the old item and creates a separate new item. It carries across entity types, properties and bindings, and relationship types. It does not complete the operational migration: downstream consumers must be reconnected, and rules and Activator alerts must be recreated. 1 The new item also uses a different definition format: TMDL, or Tabular Model Definition Language, rather than the old JSON-based structure. 3

The deadline therefore concentrates several risks into one programme:

• Continuity risk: a dashboard, agent, or alert still points to the retiring item.
• Meaning risk: copied structures exist, but business rules, descriptions, synonyms, metrics, or relationship behavior no longer match.
• Answer risk: an agent returns plausible but materially different answers.
• Authorization risk: testers can open the ontology but cannot access its source data, or migration permissions unintentionally exceed least privilege.
• Release risk: teams version the new definition but fail to provision bindings, permissions, settings, or downstream configuration in the target environment.
• Cost risk: graph refresh, definition access, modeling, and AI usage compete with production analytics for capacity.[^4]

The deadline matters now because enterprises need enough time for dependency discovery, remediation, dual running, and business acceptance. Waiting until January turns a semantic migration into an emergency cutover.

Representative scenario: a service operations ontology

The following scenario is representative and fictional; it is not a YuniQ customer claim.

A regulated service provider has an old-experience ontology that connects Customer, ServiceCase, Interaction, Entitlement, and ServiceTeam. A data agent answers questions about unresolved high-priority cases. A dashboard shows case and interaction relationships. Activator alerts notify supervisors when an entitled customer has an aging case and repeated contacts.

The platform team selects Create a copy in the new experience. Entity types, properties, bindings, and relationship types appear in the new item. The canvas looks reassuringly complete.

Yet four gaps remain:

• The escalation rule was not copied.
• The Activator alert still targets the old ontology.
• The data agent still points to the original item.
• A test analyst has access to the ontology but not the underlying lakehouse, so entity details return 403 Forbidden.

If the team judges success by visual similarity, it will miss all four. If it validates the business service, it will ask a stronger question: Can each authorized persona reach the same correct decision, and can each intended action still occur, through the new item?

That is the correct migration unit. The unit is not the ontology item; it is the decision path.

Root causes and consequences

1. Item inventories omit runtime dependencies

Workspace lists reveal ontology items but not necessarily every agent, dashboard, alert, API client, owner, business process, or source permission involved. Unrecorded dependencies surface only after cutover.

The consequence is a migration that is green at the platform layer and broken at the business layer.

2. Structural copying is mistaken for semantic equivalence

The documented copy scope is narrower than the full working system. Rules and Activator alerts need manual recreation, while downstream consumers require reconnection. 1 Even copied elements need review because a technically valid binding or relationship may not produce the same operational interpretation.

The consequence is semantic drift: familiar labels return different populations, aggregations, or paths.

3. Existing models contain explicit migration blockers

Microsoft documents two conditions that cause the migration to fail: properties configured as Defined at Binding and entities that use composite keys. The documented remediation is to remove the problematic properties or keys and retry. 5

That remediation is not purely mechanical. A composite key may encode business identity. Replacing it without a deliberate surrogate-key design can merge distinct records or split one entity into several identities.

4. Authorization is tested at only one layer

The new ontology has item-level Read, Write, and Reshare permissions, while workspace roles also confer permissions. Sharing an ontology does not grant access to other workspace items. 6 In practice, a user can discover the ontology but still lack access to a bound lakehouse. Microsoft identifies missing source access as one cause of 403 Forbidden in entity details. 5

The consequence is inconsistent behavior by persona and a temptation to solve failures by granting broad workspace roles.

5. Preview capabilities are treated as stable production contracts

The new ontology experience remains in preview. Current documentation records known constraints, including migration failures for the two model patterns above, unsupported service-principal access to the ontology MCP endpoint, no built-in rollback for ontology-agent changes, and some integration limitations. 5 7

The consequence is an operating model that assumes a feature or automation path is available before it has been verified in the tenant and region.

6. Semantic change and runtime cost are governed separately

Ontology use can generate capacity consumption from modeling, AI operations, Graph, cache, refresh, and associated Fabric items. Microsoft recommends monitoring ontology operations in the Fabric Capacity Metrics app and notes that Graph refresh schedules contribute to usage. 4

The consequence is a migration that passes functional tests but introduces an unmeasured production load.

Why common approaches fall short

“Copy it and compare the canvas”

This checks visible structure, not consumer reconnection, omitted rules, alert behavior, permissions, query results, or capacity. It proves that an item exists, not that the business service works.

“Rebuild it from memory”

Business meaning often lives in names, descriptions, source mappings, implicit conventions, prompts, and operational rules. Rebuilding from memory makes silent semantic drift likely and produces weak audit evidence.

“Give the migration team workspace Member access”

Broad access can hide the actual consumer experience. A Member may succeed where a Viewer or item-level reader fails. Production-shaped testing requires the real access path for each persona.

“Move every ontology in one release”

Ontologies differ in complexity, consumer count, regulatory impact, key design, source type, and operational criticality. A big-bang release combines unrelated failure modes and makes rollback ambiguous.

“Put the item in Git and call it recoverable”

Git integration supports ontology items, and the new definition is text-based TMDL. 8 3 That is valuable for versioning and review, but Git represents item definitions, not a complete recovery of data, permissions, tenant settings, consumer connections, schedules, or other runtime state. Microsoft explicitly notes that Git integration recreates item definitions, not item data. 9

A Microsoft Fabric solution: migrate the decision path

Use a six-layer migration architecture that separates definitions from the runtime controls around them.

Business decisions and actions
        |
Agents | Dashboards | Alerts | API/MCP consumers
        |
New-experience Fabric ontology (versioned TMDL definition)
        |
Entity types | Properties | Relationships | Rules | Metrics | Namespaces
        |
Bindings to governed semantic models, lakehouses, eventhouses, and Graph
        |
Identity | Source authorization | Tenant settings | Region | Capacity
        |
OneLake data products and operational sources

The architecture turns the migration into six explicit contracts.

Contract 1: portfolio and ownership

Create a migration register with one row per old ontology. At minimum record:

Treat an unknown owner or unknown consumer as a release blocker for high-criticality ontologies.

Contract 2: semantic equivalence

Before copying, capture a baseline that a business owner can understand:

• Entity definitions and key strategy
• Property meanings, units, sensitivity, and allowed values
• Relationship direction and cardinality
• Rules and the decisions they influence
• Metrics and their authoritative semantic-model measures
• Data bindings and refresh expectations
• A set of representative questions with expected answer facts
• Edge cases, such as missing relationships, late events, and duplicate source records

The new experience can add descriptions, synonyms, and custom metadata to ontology objects. Microsoft notes that this context improves discoverability and helps agents interpret units, sensitivity, and business definitions. 10 Use migration as a controlled opportunity to fill missing metadata, but separate parity changes from enhancements. First prove equivalent behavior; then improve the model in a later release.

Where composite keys block copying, do not simply concatenate values without analysis. Define a stable surrogate identifier, document collision and null handling, transform the source in a governed Silver or Gold data product, and reconcile entity counts and relationships before retrying the copy. This is an implementation recommendation; Microsoft documents the blocker and removal step, not this key-design pattern. 5

Contract 3: lifecycle and environment

The new experience uses TMDL files for its definition and is supported by Fabric Git integration. 3 8 Establish development, test, and production workspaces with a reviewed promotion path.

Version-control should cover:

• Ontology definition changes
• Rules and namespaces
• Model documentation
• A machine-readable dependency manifest
• Test questions and expected facts
• Environment mapping instructions

Provision separately, and verify after deployment:

• Tenant settings
• Workspace roles and item sharing
• Source access
• Environment-specific bindings
• Agent and dashboard references
• Alert destinations and schedules
• Graph refresh schedules

The release gate should compare the deployed runtime to the intended configuration. A successful definition deployment is necessary, but not sufficient.

Contract 4: identity and security

Enable only the required tenant settings for the groups conducting the migration. Microsoft documents that both Users can create Fabric items and Users can create ontology (preview) items are required to create a new ontology; the first is also required during migration from the old experience. 11

Design access by persona:

Run both positive and negative tests. Also account for propagation: Microsoft states that ontology permission changes can take up to two hours to take effect for a currently signed-in user. 6

For ontology-agent use, review regional processing and encryption requirements. Microsoft states that the agent uses delegated user access, that some non-US/non-EU scenarios require a tenant setting allowing processing outside the capacity's region or compliance boundary, and that conversation data does not currently support customer-managed keys. 7 These are design constraints that security, privacy, and legal stakeholders should approve before adoption.

Contract 5: consumer cutover

Create a reconnection checklist for every consumer. Do not use a generic “downstream tested” status.

For each data agent, operations agent, dashboard, alert, or integration:

1. Record the old item reference and owner.
2. Configure the new ontology reference.
3. Recreate omitted rules and alerts.
4. Validate authentication and source authorization.
5. Run representative questions or events.
6. Compare answer facts, relationship paths, and intended actions.
7. Capture business-owner acceptance.
8. Define the rollback action and decision window.

Pay special attention to current documented limitations. For example, Microsoft currently notes that Fabric data agent and operations agent do not work with an ontology that uses semantic models for binding, and that service-principal access to the ontology MCP endpoint is unavailable because of a known issue. 5 Confirm the current documentation again at release time because preview behavior can change.

Contract 6: capacity and operability

Baseline capacity before migration and observe the new path under realistic concurrency. Track:

• Ontology modeling operations
• Ontology AI input and output usage
• Graph refresh operations and duration
• Query latency and failure rate
• Capacity throttling during scheduled refresh windows
• Cache or storage growth where applicable
• Consumption by associated Fabric items

The Fabric Capacity Metrics app exposes ontology operations alongside other workloads. 4 Schedule Graph refresh to the decision's freshness requirement, not to the shortest technically possible interval. Separate critical production workloads from high-variance experimentation where capacity policy requires it.

A phased implementation roadmap

Phase 0: mobilize and freeze unmanaged growth

Purpose: establish control before the deadline.

• Name an executive sponsor, semantic owner, technical owner, and security approver.
• Restrict creation of additional old-experience items through normal governance; Microsoft already prevents new old-experience items through the ontology interface, although APIs and CI/CD can still create them.[^1]
• Publish the January 31, 2027 deadline and internal cutover dates.
• Define criticality tiers and minimum evidence for each tier.

Exit gate: every known old ontology has an owner, tier, and migration disposition.

Phase 1: discover dependencies and baseline behavior

Purpose: identify the actual service boundary.

• Inventory definitions, bindings, consumers, permissions, schedules, APIs, and owners.
• Detect composite keys and Defined-at-Binding properties.
• Capture production security personas.
• Record representative queries, expected facts, alerts, and latency.
• Export or version the old definition for audit and comparison.

Exit gate: no critical consumer is unknown; baseline evidence is approved.

Phase 2: remediate and copy in development

Purpose: create a testable new-experience item.

• Enable required tenant settings for controlled groups.
• Resolve blockers with business-approved key and property changes.
• Run the in-product copy action.
• Review copied entity types, properties, bindings, and relationships.
• Recreate rules, alerts, metadata, and namespaces as required.
• Commit the new TMDL definition to the approved lifecycle path.

Exit gate: the new definition is structurally complete and traceable to an approved baseline.

Phase 3: validate in a production-shaped environment

Purpose: prove semantic, security, integration, and cost behavior.

• Reconnect non-production copies of every consumer.
• Run parity questions and edge cases.
• Compare entity populations, keys, relationships, measures, and alerts.
• Test authorized and unauthorized personas.
• Exercise failure scenarios such as missing source access and delayed refresh.
• Measure capacity during representative query and refresh load.

Exit gate: zero unresolved critical discrepancies; business, security, and operations owners approve.

Phase 4: wave cutover and observe

Purpose: limit blast radius.

• Start with a low-criticality ontology that represents common patterns.
• Freeze nonessential semantic changes during the cutover window.
• Reconnect production consumers in a defined order.
• Use dual-run comparison where the consumer permits it.
• Observe answers, alerts, failures, latency, and capacity for the agreed period.
• Roll back consumer references if a critical threshold is breached.

Exit gate: each wave meets its service-level and semantic acceptance thresholds.

Phase 5: retire the old path and prove closure

Purpose: remove hidden dependency on the retiring experience.

• Confirm that no consumer calls the old item.
• Remove obsolete alert and integration references.
• Revoke unnecessary permissions.
• Retain required audit evidence according to policy.
• Remove the old item only after the approved rollback window.
• Update support runbooks and the service catalogue.

Exit gate: the retirement register shows owner approval, dependency closure, and tested operation on the new experience.

Governance, security, adoption, and cost considerations

Governance

Assign a business owner to each namespace or domain vocabulary. Namespaces help distinguish concepts that share a label but have different meanings, such as Sales Customer and Finance Customer. 12 Require changes to entity identity, relationships, rules, and metrics to include impact analysis and consumer review.

Security and compliance

Do not equate ontology sharing with source authorization. Validate the full access chain and log both allowed and denied paths. Review preview-region processing, customer-managed-key limitations for conversation data, and any cross-workspace source path before production use. 6 7

Adoption

Give business testers question-based acceptance scripts rather than asking them to inspect TMDL. Train support teams to distinguish a missing ontology permission from a missing source permission, stale Graph data, an agent limitation, and a capacity issue. Publish the new item location and transition date to consumers.

Cost

Treat refresh frequency and AI query volume as service-design choices. Use the Capacity Metrics app to establish a baseline and set thresholds. Include associated Graph and other Fabric item consumption, not only ontology-labeled operations. 4

Preview risk

Maintain a documented preview exception with an owner, approved use cases, known limitations, review date, and fallback. Recheck Microsoft documentation immediately before each production wave; a preview feature can change faster than an annual architecture standard.

Success metrics

Measure business continuity and semantic trust, not just migration throughput.

Thresholds should reflect criticality. The table's example values are recommendations, not Microsoft product guarantees.

How YuniQ can help

YuniQ's published Microsoft Fabric services align with the work this migration requires. Its Fabric Strategy & Readiness capability includes current-state diagnostics, use-case prioritization, capacity planning, workspace topology, and security, governance, and operating-model design. Its governance and DevOps capability includes least-privilege Microsoft Entra ID role design, Purview integration, lineage, development/test/production separation, Git CI/CD pipelines, monitoring, and capacity alerts. 13

For implementation, YuniQ describes a delivery framework of Discover, Architect, Prove, Migrate & Build, Validate & Launch, and Optimize & Scale. The service page specifically includes dependency mapping, semantic modeling, automated reconciliation, access testing, dual-run comparisons, user acceptance, cutover, capacity optimization, and team enablement. 13

Applied to an ontology retirement programme, that service scope can support:

• An inventory of old ontologies, sources, consumers, identities, and business owners
• A target workspace, security, semantic, and lifecycle blueprint
• A proof of value using one representative ontology and its real consumers
• TMDL-based release controls and environment separation
• Semantic reconciliation, access testing, and dual-run validation
• Cutover planning, operational monitoring, and handover

These statements reflect capabilities described on YuniQ's service page. They do not imply a Fabric ontology customer result or a guarantee of zero disruption.

Practical next steps

Start with a ten-business-day control sprint:

1. Enumerate all old-experience ontology items and assign owners.
2. Identify which ones support agents, dashboards, alerts, or APIs.
3. Flag composite keys and Defined-at-Binding properties.
4. Select one medium-complexity ontology as the migration pilot.
5. Capture ten to twenty decision-oriented questions and expected facts.
6. Map required tenant settings, roles, source permissions, and regional constraints.
7. Copy the pilot, recreate omitted behavior, and reconnect non-production consumers.
8. Run semantic, security, operational, and capacity tests.
9. Convert the evidence into reusable release gates for later waves.
10. Set an internal completion date that leaves a contingency window before January 31, 2027.

The key executive decision is simple: fund this as a controlled business-service migration, not an administrative copy task. That framing creates the time and ownership needed to protect the meanings, decisions, and actions already built on Fabric ontology.