Fabric migration planning: lakehouse, warehouse and the resources you need

Inventory the service that people rely on

Begin with reports, extracts and downstream processes that use the existing platform. Record their owners, timing needs and known exceptions. A table may look unused in a database review while a month-end workbook depends on it. Ask business teams what they would lose if the current environment stopped tomorrow. Their answers reveal dependencies technical inventories can miss.

Separate migration goals from longstanding improvement requests. Moving a report and redefining its metrics together makes reconciliation harder. Some improvements justify that complexity, but they should be explicit decisions. When requesting a Microsoft Fabric data architect, share the dependency map and reason for change. A suitable resource should ask which outcomes must remain stable and which may change. That conversation helps avoid a plan driven entirely by source-object counts while overlooking the business services that make those objects important. Include a named business approver for each service so acceptance does not depend on finding an available reviewer at the last moment.

Compare lakehouse and warehouse against the actual work

Microsoft's decision guide distinguishes lakehouse and warehouse by workload and development approach, including Spark-oriented and T-SQL-oriented work. Use that distinction as an assessment starting point rather than a universal rule that one option is more modern. Discuss transformations, source formats and the skills of people who will maintain the result.

Ask the architect to document the choice with a representative example. What becomes easier, what needs different tooling and which responsibilities are introduced? If both approaches are proposed, require a clear reason for their boundary. A hypothetical business with established SQL reporting processes may prioritize maintainable transformation logic, while another may have file processing needs that change the assessment. Those are planning examples, not product-selection verdicts. Validate the recommendation using your own sources and consumers before treating an architecture diagram as proof of readiness. The decision should remain understandable to internal maintainers after the person who proposed it has completed their assignment.

Staff the boundaries between architecture and delivery

Architecture defines intended boundaries, while engineering proves and implements them. Reporting specialists verify that analytical outputs continue to answer agreed questions. Platform owners approve access and operational arrangements. One person may cover several responsibilities in a small migration, but the responsibilities should remain visible.

A Microsoft Fabric data engineer is central when ingestion and transformations need rebuilding. A Power BI specialist may be needed when reports or semantic models change. Do not expect an administrator to approve business metric differences, or a report developer to own every upstream migration decision. Assign a migration lead who resolves dependencies and maintains a decision record. This helps external resources work with existing employees and partners without competing assumptions. Ask each specialist what inputs they need and what evidence they will provide before the next stage. Include a route for unresolved technical questions so a dependency does not remain invisible while everyone reports progress on their own isolated tasks.

Make the pilot representative of difficult work

Choose a pilot with meaningful transformation, a known exception and a real consumer. The easiest source may demonstrate connectivity while teaching little about risk. Conversely, starting with the most critical workload can create unnecessary pressure. Agree a useful but controlled slice with an available reviewer.

Include history and corrections where relevant. Ask how the new environment handles a changed record, a missing reference and a repeated load. Microsoft describes the lakehouse as supporting engineering and analytical access; your pilot must still establish the particular delivery behavior the business needs. Require editable artifacts, assumptions and evidence rather than only a demonstration. A Microsoft Fabric analytics engineer can help assess the prepared data presented to consumers. Review what the pilot actually proved before applying its pattern broadly. Success with one source does not establish that every source shares the same update, security or recovery characteristics. Record which additional checks are required for the next migration wave.

Reconcile meaning as well as record counts

Record counts do not prove that values belong to the correct periods, entities or categories. Define comparisons around important business outputs, including balances, quantities, selected transactions and exception populations. Record the agreed source of truth and explain differences instead of assuming every mismatch is a defect in the new platform.

During parallel review, use identical filters and timing where possible. If old and new systems load at different times, distinguish timing differences from transformation differences. Ask business reviewers to approve meaningful examples, including corrections and incomplete records. A hypothetical sales report may match in total while assigning activity to the wrong region, so include relevant breakdowns. Preserve comparison evidence for later investigation. Migration acceptance should distinguish intended differences, unresolved questions and authority to approve the transition. This is more informative than stating that data copied successfully and reports opened without errors. Keep exception decisions attached to the wave that introduced them so later teams understand why an apparent mismatch was accepted.

Plan cutover as a controlled business decision

Cutover should specify which consumers switch, who communicates the change and which conditions must be satisfied. Include source delivery, access checks, reconciliation and support readiness. Identify the people who may delay transition if evidence is incomplete. A deployment window is insufficient if the finance reviewer or operations owner is unavailable.

Discuss the response if the new output becomes unreliable after switching. Depending on the design, recovery might return consumers to an earlier route, repair a delivery or withhold an affected report. Agree the approach for the environment rather than inventing it during an incident. Keep the previous service available only under an approved transition plan with responsibility for parallel operation. Document when it may be retired and which evidence must remain. This avoids attention to launch followed by indefinite, poorly owned coexistence. Resources should know who approves recovery, how users are informed and which checks are required before the new route resumes normal service.

Choose resource models for migration stages

The Hourly Model is useful for architecture review, dependency assessment or targeted investigation of blockers. Require a written recommendation with assumptions and decisions needed. Project Based hiring suits a bounded migration wave with defined sources, consumers, acceptance evidence and handover. An unreviewed inventory is not sufficient scope for a final delivery commitment.

A Dedicated Resource supports an extended program with several waves and evolving priorities. Define how the person divides attention between migration and existing-platform support. If the same engineer maintains both, reflect that in the plan. North American and European teams working with India-based resources should agree overlap for design reviews, validation and cutover. Different stages may require different windows. State language, access and environment restrictions early and assess individual fit. Location should not replace a practical conversation about responsibilities and the availability of your decision makers. A resource may be ready to build while business approvals remain the actual constraint on migration progress.

A Microsoft Fabric BI consultant can help connect the migration plan to reporting expectations and the way business teams use information. Include that perspective when defining acceptance: moving data successfully is only part of the requirement if users still cannot reconcile a report or understand the new reporting process.

Use retirement and ownership as final acceptance criteria

Migration is incomplete if the new platform works but nobody owns routine changes. Confirm source contacts, runbooks, release procedures and access administration. Ask a maintainer who did not build the pilot to perform an ordinary support task. This reveals whether handover is usable rather than merely present.

Review remaining consumers before retiring the old environment. Confirm whether archived outputs or historical comparisons need continued access through an approved route. Keep improvements deliberately deferred from migration in a visible backlog so they do not become undocumented changes during stabilization. Review the first relevant business cycle after cutover. The goal is a sustainable reporting service with clear owners and accepted outputs. Resource planning therefore includes the final operational steps, not just deployment of the last transformation. That boundary helps the business understand what it is buying and helps specialists deliver work that remains dependable after their assignment finishes and the new platform becomes part of normal operations.