¡Hola! Hi — and thank you for being a subscriber of The Data Massagist newsletter. Just for you, here is Edition #6.

In “From Blank Canvas to Data Architecture: Designing Greenfield Platforms” (Edition #5), I explored how to architect a modern data platform from scratch. But most large organizations don’t start with a blank canvas — they inherit decades of systems, scripts, silos, and technical debt.

This edition focuses on what really matters: turning design into reality. Specifically, how to execute a migration to a modern analytics platform in a smooth, controlled, and business-driven way. The guidance below is technology-agnostic, while drawing on proven practices from real-world implementations of Azure Databricks and Microsoft Fabric.

Both Microsoft and Databricks are recognized by analysts like Gartner and Forrester as leaders in modern data and AI platforms, reflecting their enterprise-scale capabilities. Notably, Azure Databricks has been benchmarked to run 21%+ faster than the same Databricks service on other clouds, thanks to its native integration with Microsoft’s AI services and Power Platform ecosystem — improving both performance and productivity.

The Real Challenge Isn’t Architecture. It’s Migration.

Moving from legacy platforms (Teradata, Exadata, Hadoop) to a modern lakehouse isn’t a technology upgrade. It’s an enterprise transformation.

And how leaders approach that transformation determines whether it becomes a growth accelerator — or an expensive distraction.

The Real Reason Companies Migrate

If cost reduction is the primary motivation, the initiative is already underpowered.

Yes, cloud platforms like Microsoft Azure often reduce infrastructure and maintenance costs. But organizations migrate for much bigger reasons:

• Speed & Agility: Decoupled storage and compute allow on-demand scaling and faster experimentation. After modernizing its analytics platform, AT&T Mexico achieved 3× faster data science cycles and eliminated months of environment provisioning delays.

• AI & Innovation: Legacy systems struggle with advanced analytics. Migration enables native AI/ML and generative AI integration — turning data platforms into innovation engines.

• Data Democratization: Modern platforms unify silos and enable governed self-service analytics. Apollo Hospitals consolidated dozens of systems into Fabric, cutting data latency from hours to seconds. ARcare eliminated 6–8 hours of manual daily work using Fabric.

• Resilience & Flexibility:A modern lakehouse supports SQL and machine learning side by side, structured and unstructured data together. UST migrated 20 years of HR data to Fabric in under a year, cutting ingestion times by 50% and creating a future-proof analytics foundation.

• Total Cost of Ownership (TCO: While not the sole driver, cost optimization remains important. AT&T Mexico realized a 300% ROI after moving to Azure Databricks and retiring on-prem infrastructure.

In short, companies migrate to become more agile, intelligent, and innovation-ready.

A Disciplined Six-Phase Approach

Moving an enterprise data estate is like relocating a city—you need a plan, a phased roadmap, and careful execution.

Based on extensive field experience, successful migrations follow a structured Six-Phase Pattern:

Phase 1: Discovery & Assessment

This phase establishes a fact‑based view of the current data estate:

• What data, pipelines, workloads, and reports exist

• What is actively used versus technically present

• Where cost, performance, and operational risks truly sit

The goal is not documentation—it is clarity. Leaders gain a realistic understanding of scope, complexity, and business priorities before approving timelines or budgets.

Phase 2: Target Platform Design

Here, organizations define the future state:

• Data architecture (lakehouse, warehouse, domains)

• Consumption patterns (BI, AI, data products)

• Security, governance, and operating model

In many cases, this phase benefits from a technical proof of concept to validate performance, integration, or workload compatibility based on the available options (ie. Azure Databrikcs and/or Microsoft Fabric, or another platform such as Snowflake)

The outcome is a validated target platform blueprint, reducing architectural and strategic risk early.

Phase 3: Strategy & Migration Design

This phase defines:

• The migration approach (wave‑based, domain‑driven)

• Tooling and automation strategy

• Data movement, transformation, and validation patterns

• Clear criteria for success—defined in business terms

Crucially, this is where organizations define what “done” means. Not when data is copied—but when it is usable by the business.

Phase 4: Minimum Viable Product (MVP)

A single high‑value use case is migrated end‑to‑end:

• Data ingestion

• Transformation logic

• Business consumption

This phase builds confidence, exposes assumptions, and creates a repeatable reference for future waves. It also aligns technical teams and business stakeholders around a shared definition of success.

Phase 5: Execution

Migration is executed in waves, typically by business domain or use case. Each wave includes:

• Data movement

• Development and code conversion

• Testing and validation

• Deployment to production

A wave is complete only when Gold‑layer assets are live and actively consumed, such as:

• Business dashboards and reports

• Semantic and ontology models

• Data agents and governed data products

• AI‑assisted experiences, including natural‑language analytics

This approach ensures progress is measured by business impact, not technical activity.

Phase 6: Old Platform Decommission

Only after domains are fully live on the new platform should legacy systems be retired:

• Parallel runs are stopped

• Infrastructure and licenses are eliminated

• Operational complexity is reduced

This phase is often underestimated—but it is where cost savings, simplification, and risk reduction are fully realized.

Why Wave-Based Migration Works

Migrating everything at once creates unnecessary risk. Wave-based migration organizes delivery around business domains — each wave delivering a complete, usable data product.

Here are some of the observed benefits:

• Lower Risk: If something goes wrong, only one domain or workload is affected, not the entire enterprise.

• Faster Feedback: Early waves deliver actual business output on the new platform (e.g. one department’s analytics). Users and engineers learn what works and what needs adjustment, so you can adapt in subsequent waves.

• Quick Wins: High-value use cases can go live in Wave 1, providing success stories to champion the program internally. This maintains executive support for the longer journey.

• Manageable Change: From the end-user perspective, changes are gradual. Teams can be onboarded to the new tools in stages, and training can be targeted by wave.

• Parallel Workstreams: With the right resources, you can execute multiple waves at once (for different domains) to accelerate overall timeline.

A wave is complete only when Gold-layer assets are live and actively consumed — dashboards, semantic models, governed data products, AI experiences.

You can learn more about Wave Planning in the Azure Migrate documentation at Microsoft Learn.

What Makes a Migration Wave Successful

A wave‑based migration organizes the journey around business domains, not around infrastructure components or technology layers.

Each wave represents a complete, end‑to‑end migration of a domain:

• Its source data

• Its transformations and logic

• Its consumption layer

• Its users and downstream dependencies

The platform evolves incrementally, but the business experience remains coherent.

This is not “breaking the migration into smaller chunks.” It is delivering finished data products, one domain at a time.

Inside a Migration Wave

A wave‑based migration is led and prioritized by the Solution Item, not by the platform team. Each wave functions as a self‑contained delivery cycle with clear entry and exit criteria.

A mature wave typically includes:

• Validation Expectations Defined Upfront. Successful wave‑based migrations begin by removing ambiguity early. Before any data is moved or logic is rewritten, organizations align on what “acceptable” means. This includes defining tolerance thresholds for data accuracy, establishing reconciliation rules against the legacy platform, and documenting known limitations or exceptions. By setting these expectations upfront, teams avoid the most common migration failure mode: endless re‑validation cycles driven by shifting criteria. Clear validation guardrails allow delivery teams to move with confidence and business stakeholders to trust the outcome.

• Asset Mapping and Dependency Analysis. Each Solution Item within a wave is anchored by a comprehensive asset inventory. Databases, tables, views, stored procedures, scripts, and embedded business logic are mapped alongside upstream feeds and downstream consumers. This dependency analysis creates a shared understanding of scope and impact, ensuring that nothing critical is overlooked. The payoff is predictability—cutovers are no longer moments of discovery, but controlled transitions backed by full visibility.

• Clear Testing Scope, SLAs, and Timelines. In wave‑based migrations, testing is designed as a business commitment, not a technical afterthought. For every wave, teams explicitly define the scope of user acceptance testing, clarify ownership and responsibilities, and agree on performance SLAs and timelines. Most importantly, business and IT align early on what “done” truly means. This shared definition eliminates late‑stage debates and enables decisive go‑live decisions based on agreed criteria rather than subjective judgment.

• Modernization of Pipelines and Logic. Wave‑based migration is not about replicating legacy patterns in a new environment—it is about improving them. Stored procedures and scripts (i.e. Teradata BTEQ scripts) are re‑implemented as modern Notebooks and Pipelines, while joins, aggregations, and transformations are optimized for Microsoft Fabric or Azure Databricks. The Medallion architecture is applied consistently to enforce separation of concerns and scalability. This modernization ensures the target platform is not only functionally equivalent, but structurally better positioned for future growth.

• Application and Reporting Readiness. Data rarely lives in isolation. As part of each wave, all domain‑specific applications and reports are assessed to enable seamless re‑pointing to Microsoft Fabric or Azure Databricks when required. This proactive readiness work protects business continuity and avoids last‑minute surprises at cutover. By treating applications and reporting consumers as first‑class citizens in the migration, organizations ensure that value is realized immediately—not weeks after the data arrives.

• Testing, Parallel Runs, and Controlled Cutover. No domain moves forward without proof. Before any cutover, each wave completes user acceptance testing, performance testing, and parallel runs against the legacy environment that we are trying to retire. These parallel executions validate not only correctness, but also performance and operational behavior under real workloads. Only domains that meet agreed criteria advance to cutover, reinforcing discipline and minimizing risk.

• Semantic Models for AI Readiness (Optional but Strategic). In case the target destination is Microsoft Fabric, I do recommend extending each wave by delivering a Semantic Model alongside the Gold layer. This accelerates Power BI adoption, enables Copilot experiences, and lays the foundation for Fabric's Data Agents and AI‑driven use cases. When included, semantic models transform migration from a data movement exercise into an intelligence accelerator—positioning the platform for insight, automation, and decision support from day one.

How Microsoft Can Help Migrate Fabric & Azure Databricks Faster

Finally, if all this sounds daunting, remember that you’re not on your own. Microsoft has invested in tools and expert services to assist organizations in migrating to modern data platforms (whether Microsoft Fabric, Azure Databricks, or a combination of both). Two programs are especially worth noting:

• Microsoft Fabric Migration Assistant: Automates discovery, code analysis, and conversion. It jump-starts early phases by identifying what can be auto-converted and what requires refactoring — reducing risk and manual effort. Please, read Tino Tereshko 🇺🇦 and Priyanka Langade blog about the how Fabric Data Warehouse Migration Assistant to make your journey faster, more reliable, and easier to manage.

• Microsoft’s Cloud Accelerate Factory (CAF) team: For large transformations, Microsoft’s Customer Success organization works side-by-side with your team using specialized experts, automation frameworks, and proven repeatable IP. The result: faster, more predictable wave-based execution.

Together, tooling and expert execution significantly compress timelines while reducing risk.

CAF Deep Dive

Due to the importance and potential impact of Microsoft’s Cloud Accelerate Factory (CAF) in your organization, I’d like to provide a bit more context.

CAF is a benefit of Azure Accelerate designed to help you jumpstart Azure projects. In the analytics space, this typically means modernizing reporting and analytics workloads—for example, migrating on-premises SQL Server reporting to Power BI and enabling real-time insights—with expert guidance and funded investments.

For analytics scenarios, CAF can support migrations from on-premises SQL Server, Azure SQL DB/MI, or Azure Synapse Spark into a Microsoft Fabric Lakehouse or Warehouse. It also helps ingest data into Microsoft Fabric from sources such as Azure SQL DB/MI, PostgreSQL, MySQL, Oracle, flat files, AWS Redshift, Hadoop, Fabric Shortcuts (SQL Server), Snowflake, and others.

In addition, CAF can assist with:

• Migrating SQL Server Reporting Services (SSRS) and Analysis Services (SSAS/AAS) to Power BI on Microsoft Fabric

• Simplifying the transition from Power BI Premium (P SKU) to Microsoft Fabric (F SKU) workspaces within the same region, with the appropriate architectural considerations

As Stephen Helwig shared recently:

“Over the last 18 months, our CAF team has helped customers build 550+ AI solutions on Azure—not to mention the thousands of migration, modernization, and analytics projects completed over the last four years.”

You can learn more about CAF and Azure Accelerate here.

The Executive Mandate

For CEOs, CIOs, and CDOs:

A data platform migration is not an IT refresh. It is a strategic inflection point.

Done poorly, it consumes resources. Done well, it unlocks speed, intelligence, and competitive advantage.

The question is not whether to modernize — AI innovation makes that inevitable. The real question is whether migration is treated as a technical project — or as a business transformation program.

When Gold-layer assets are trusted and actively used — when teams can see, understand, and act on data in real time — you are no longer migrating.

You are modernizing the enterprise.

And in today’s market, that difference defines the leaders.

So, speak to your account teams today on how Microsoft can support your migrations needs and access to the CAF team to leverage this zero-cost service.