Some caveats first. The account comes from EY, the consultancy that did the work. It doesn't name the insurer, and it gives no cost, timeline, speed-up or error-rate figures. Everything below is EY's description of the program and not an independently audited result.
The starting point: a SAS estate with real business weight
EY says SAS Enterprise Guide was deeply woven into the insurer's reporting, analytics and daily operations. The case study gives these figures:
- 1,612 SAS Enterprise Guide projects in the starting inventory.
- More than 100 people across the business used it. Their areas were life and non-life insurance, actuarial work, finance, risk, data and analytics, and distribution.
- More than 1,500 SAS business workloads in the broader transformation program.
EY doesn't explain how the 1,612-project inventory and the 1,500-plus workload figure relate. They may count different things, so don't treat them as the same number.
These workloads carried business rules, transformations and calculations used in management, regulatory, financial and actuarial work. EY's point is that moving them to Azure Synapse couldn't be reduced to translating code from one language to another. Continuity and functional accuracy mattered as much as the technical move.
Two migration patterns, not one
EY says a single route would not fit every project, so the program used two patterns:
- Lift & Shift: refactor the project while keeping the same inputs, outputs and business logic.
- Rebuild: redesign the most complex workloads as durable, integrated data products aligned with the target architecture. This means balancing modern data-modeling practice and the corporate platform architecture against each insurance domain's business and regulatory demands.
The "Business Migration Factory"
EY set up what it calls a repeatable Business Migration Factory. Before broad execution, the team did the following:
- Reviewed and classified the inventory.
- Checked data readiness.
- Designed governance and defined the method.
- Onboarded the people who would run the factory.
It then ran 30 Lift & Shift migrations to test the main route. It also ran three Rebuild pilots. EY doesn't report durations or measured outcomes for these pilots.
A central Solution Center sets standards for governance, architecture, quality, enablement and delivery. Domain teams then migrate in waves. Business priority, complexity and data readiness decide the order. EY says the factory covers seven business domains but doesn't list them.
The workload lifecycle
Every workload goes through the same steps:
- Define and refine the scope.
- Check that the target platform holds the data the workload needs.
- Choose Lift & Shift or Rebuild.
- Use the insurer's GenAI-based SAS Migration Tool to speed conversion to SparkSQL or PySpark.
- Finish and optimize the migrated notebooks.
- Run unit, integration and regression tests.
- Compare SAS and Synapse outputs.
- Get formal validation from the business.
- Deploy, stabilize and hand over the asset.
The AI sits in only one step of nine. EY says generative AI helped analyze and convert code but did not replace engineering judgment or business knowledge. Functional equivalence, output reconciliation, code quality and business acceptance act as gates. EY doesn't say which model or provider powers the tool, how much conversion is automated, or how often the output needed human correction.
Quality checks and user adoption
Quality checks run through the whole process instead of waiting until the end. They cover:
- schemas and input completeness
- transformation rules
- referential integrity
- reconciliations
- output consistency and freshness
- differences between SAS and Synapse results
On adoption, EY says business users learned by working with real code and data in actual validation sessions. Acceptance walkthroughs, formal sign-off, hands-on Synapse clinics, documentation and knowledge transfer prepare them to own the migrated solutions. The delivery team combined local insurance, finance, risk, actuarial, data and change expertise with offshore architecture, development and testing capacity.
Where the program stands
This is a work in progress. The insurer is progressively migrating or rebuilding critical workloads, and SAS and Synapse run side by side. EY defines success in qualitative terms:
- Critical workloads are migrated, adopted on the corporate data platform and accepted by their owners.
- Performance, maintainability, compliance, documentation and target-architecture alignment hold up.
- Delivery stays predictable, with functional equivalence, clean handovers and stabilization.
Dependency analysis and readiness checks are laying the groundwork to retire legacy SAS components "when the organization is ready." No retirement date is given, and EY doesn't say any retirement has happened.
Analysis: what Windows and Azure admins can take from this
These points are my own reading of the workflow, not measured EY results.
- AI conversion speeds the first draft. The expensive parts are validation, reconciliation and business sign-off, and EY built those in as hard gates.
- Output comparison is the core control. Running SAS and Synapse in parallel and reconciling results is what lets a regulated team trust the new platform.
- Users are part of the migration. The people who know what a calculation means are the same people who must approve the replacement.
- Tiering workloads pays off. Separating simple refactors from complex rebuilds avoids both over-engineering easy jobs and under-engineering hard ones.
A platform question worth asking
The destination here is Azure Synapse, and Microsoft's own direction has been moving toward Fabric. Microsoft Learn publishes a migration runbook for Synapse dedicated SQL pools to Fabric Data Warehouse. It advises starting small and simple, and preparing for multiple small migrations. Microsoft also offers a Fabric Migration Assistant for Data Warehouse. The documentation points to it as the way to start an automated migration.
Third-party commentary is more pointed. One consultancy's 2026 analysis says Dedicated SQL Pools, Synapse Spark and Synapse Pipelines have not been officially retired as of 2026. The same piece argues they are end-of-roadmap. It also notes that Azure Synapse Data Explorer was formally retired on October 7, 2025. Another firm describes Synapse as in maintenance mode, still working and still getting security patches, with new capabilities landing in Fabric. Treat these as commentary, not Microsoft statements. The EY case study doesn't say whether the insurer plans a later move to Fabric.
Anyone planning a similar SAS migration should check Microsoft's current Synapse and Fabric lifecycle guidance before fixing the target platform. The EY case study doesn't address it. A Spark-based notebook estate may be portable, but verify that assumption for your own workloads.
Bottom line
EY's account shows a disciplined, governed way to use AI-assisted code conversion at scale. It also avoids any claim that AI replaces the validation work. The thing to copy is the factory: shared standards, wave-based sequencing, side-by-side output comparison and business sign-off. The thing to treat with caution is the lack of published results. Until the insurer or an independent party reports performance, cost and quality data, this remains an instructive blueprint and not a proven success story.