Data Modernization Strategy: 3 Pillars That Move Together

Most of the data modernization programs we get called in to rescue stalled for the same reason. The warehouse moved, and the pipelines ran, while the applications that write the data and the AI workloads that read it sat in a "phase two" that never got funded. Eighteen months later, the company is paying for two estates and still can't put an AI agent in front of a customer.

We've spent more than 18 years building on AWS, a good share of it on secure, compliance-heavy AI systems for banks, insurers, healthcare payers, and manufacturers. Across that work, one pattern holds up. A data modernization strategy that runs the data platform, the application and database layer, and the AI layer as three separate projects tends to produce three partially finished systems and a budget that has to be defended twice.

Our running example is a property and casualty insurer, made up but typical. It writes about $1.6 billion in premium a year, mostly commercial auto and small-business policies sold through independent agents in 14 states, and its Dublin subsidiary writes the EU risks. Two years ago it moved its analytics off an IBM Netezza appliance and onto Amazon Redshift, on time and roughly on budget.

Then the bills arrived. The claims system on SQL Server and the policy administration system on Oracle still wrote to the old schemas, so the nightly loads still ran through Netezza, and finance kept pulling loss-ratio reports from there. A claims-triage assistant built last year looked good in the demo, then stalled at the security review, because it read claimant records from both sides of the Atlantic through one service account. The second phase that was meant to fix both was never funded.

What Is a Data Modernization Strategy, and Why Do Most Stall Before Production?

For the insurer, it would have been a plan that said which systems move, in what order, and the date each old one gets switched off, covering the claims and policy systems and the triage agent as well as the warehouse. In general terms, a data modernization strategy is that plan, with a target design, the controls each piece needs and what it should cost. It's finished when production systems run and the old contracts end.

That last part is where the insurer came up short. Its first program had a target design and a migration plan for the warehouse, but nothing tied that migration to the claims database feeding it or to the AI use case that was supposed to pay for it. Plenty of companies have a slide titled "data strategy." Far fewer have a plan with switch-off dates in it.

The insurer was far from alone. A Harvard Business Review Analytic Services survey for Cloudera found that "Only 7% say their organization's data is completely ready for AI adoption." When we look at estates like the insurer's, storage and data volume are almost never the problem. What decides readiness is whether the systems around the data moved on the same schedule as the data itself. It shows up in McKinsey's 2026 State of AI survey too, where 44% of respondents said AI was scaling across their enterprise. The rest were still experimenting or piloting, as the insurer was.

What are the warning signs that your program is drifting?

The insurer heard all five in the same quarter, and none of them came down to the technology it had picked. Each traced back to a plan that moved one pillar and parked the other two.

What Are the Three Pillars of a Data Modernization Strategy?

At the insurer, they were Redshift and the old Netezza appliance, the Oracle and SQL Server systems that wrote claims and policy data, and the triage assistant that read it. In general terms, that's the data platform, the applications and databases, and the AI and decision layer, with governance, security and funding running underneath all three.

Each of those had a different owner. The CIO's data team ran Redshift, a separate applications group ran the policy and claims systems on their own vendor contracts, and the triage assistant belonged to an innovation team that reported to the chief claims officer. Each had its own renewal calendar, and nobody was planning across them. Our data modernization framework goes deeper on the first pillar, splitting the platform into architecture, governance and consumption, but a strategy has to look one level up, at all three.

The second pillar is the one most data modernization roadmaps underweight, and the insurer's was no exception. A lakehouse can't be cleaner than the Oracle and SQL Server schemas feeding it, and twenty years of rating and reserving rules sat in stored procedures nobody wanted to touch. In our application and database modernization work, agents handle the code analysis, dependency mapping and test generation for logic like that. The engineers spend their time on the harder call, which is how the reserving rules should look once they're out of SQL Server.

The insurer's business case sat in the third pillar, in faster claims triage. It's also the pillar we'd scope on day one, even when the first production agent ships in a later slice, because an agent inherits every weakness in the data beneath it. Our AI agents work closes each of its five stages with a signed exit.

Why Do the Three Pillars Have to Move Together?

The insurer found out the expensive way. Moving only the warehouse left Netezza running, because the claims system was still feeding it, and the triage assistant had no governed data to read. All three pillars share schemas, pipelines and access policies, and moving one on its own tends to cause both of those problems together. The legacy savings and the AI payoff then land in different fiscal years, if they land at all.

The insurer's case is a common one, and the figure below shows the other two ways it tends to go.

None of this means you modernize everything at once. Trying to boil the ocean is how programs end up with a two-year runway and no production system to show for it. The insurer's second program moved all three pillars together, but for one business domain at a time.

How do you sequence the pillars without boiling the ocean?

One business domain at a time, carried through all three pillars before the next one starts. We call that a domain slice, and it could be claims, card payments or plant operations depending on the business. The insurer's first slice was commercial auto claims. Its SQL Server claims database was refactored, governed claims data products went onto the lakehouse, and the claims-triage agent shipped against them.

Five sequencing rules keep slices honest, and here's how each one played out in the insurer's claims slice:

The AI layer adds requirements most warehouse migrations never had to meet. Ammar Nizami, Senior Forward-Deployed Engineer in our Data Engineering practice, put it plainly in his analysis of lakehouse design for agentic AI: "Storage is seldom where this goes wrong." His point is that the gaps sit in the catalog, the policy model and the write path. That's why the insurer built those pieces inside the claims slice, alongside the migration, rather than leaving them for later.

What Does the Target Architecture Look Like for Data Modernization on AWS?

Something like the reference architecture below. It's the pattern most of our data platform work starts from, and the service names matter less than the decisions at each layer. At the insurer, the two that mattered most were which system stayed authoritative for claims during the parallel run, and where the reserving logic would live once SQL Server was gone.

Warehouse, lakehouse, or data mesh: which pattern fits?

For most companies in the $500M to $5B range, we land on a lakehouse with domain-owned data products and centrally enforced policy, and that's where the insurer ended up. It maps cleanly onto domain slices and gives agents one governed place to read from. The Netezza appliance was the awkward part. Two years after the move it was still running "just in case," which our Redshift migration consulting team calls "a second bill, not a safety net."

What does an AI-ready data platform need that a BI platform didn't?

Agents use data very differently from dashboards, and Ammar's lakehouse analysis puts it in one line: "Agents query nothing like dashboards do." The insurer's triage agent hit a dozen tables in a few seconds on behalf of a named adjuster, and within weeks the claims team wanted it to suggest reserve changes as well. Those two facts produced the five additions in the table.

How Do You Build Compliance Into a Data Modernization Strategy?

By designing controls into the pipelines and generating audit evidence while the migration runs. Lineage, reconciliation reports, access logs and decision records should come out of the build as by-products, because reconstructing them after go-live is slower and costlier, and it's the main reason security teams delay sign-off. That's what happened to the insurer's first triage pilot.

This matters more as AI moves into regulated workflows. Ram Tiwari, Forward-Deployed Engineer and Spark data engineer at Mactores, makes the point directly in his piece on data pipeline modernization on AWS: "Compliance controls belong inside the pipeline." We'd add that they belong inside the retrieval layer too, because that's where an agent decides what an adjuster is allowed to see.

Which regulations shape the strategy for US and European companies?

For the insurer, the US side meant SOX over the reserve figures, GLBA and the state insurance data security laws modeled on the NAIC's model law, and the NAIC's model bulletin on insurers' use of AI, which 29 jurisdictions had adopted as of October 2026. The Dublin subsidiary added GDPR and DORA, since insurers count as financial entities under DORA. The EU AI Act was lighter than the team expected, because Annex III lists risk assessment and pricing for life and health insurance as high-risk, and a P&C claims-triage agent isn't on that list.

The insurer designed to the stricter rule once and applied it in both regions. Running a separate EU stack would have doubled the governance work without lowering the risk, and we'd advise the same for any company operating on both sides of the Atlantic.

What audit evidence should the program produce by default?

Insurers sit closer to banks than to retailers here. Our financial services data modernization work is scoped on the principle that "The evidence an examiner will ask for is generated while the system is being built." As always, we design against these frameworks, and your counsel and auditors make the final call on compliance.

How Much Does Data Modernization Cost, and How Do You Fund It?

Mostly on how much legacy you're carrying and how long you carry two of everything. At the insurer, the biggest hidden cost was one it was already paying: two warehouses, every month, for two years.

We'd rather give you the drivers than a ballpark that ignores your estate. Here's how each one showed up at the insurer, and how we'd contain it:

Where does the budget actually come from?

From spend you already have, in most cases. Ammar's piece on Oracle and SQL Server modernization to Amazon Aurora argues that "a good part of the AI budget most enterprises think they need is already sitting inside existing IT spend." At the insurer, it sat in the Netezza support contract, the SQL Server licenses on the claims system and an integration tier that billed hours to keep itself alive. Each one became a reallocation candidate once the slice that depended on it was retired.

For eligible workloads, AWS's Migration Acceleration Program (MAP) can cover part of the migration cost as well, and your account team will know whether yours qualify. It's worth asking early, because the answer can change which slice goes first.

Which commercial model protects your budget?

A CFO can budget against a date written into the statement of work, and the insurer's CFO asked for exactly that the second time around.

What Does a 90-Day Data Modernization Roadmap Look Like?

One domain slice, about 90 days, five gated phases: scope and commit, prove the hardest part, build, validate in parallel against the legacy system, then cut over and retire it. That's the five-phase delivery method we run, and across our engagements the median time to production is 12 weeks.

For the insurer's claims slice, the phases overlapped on purpose. Validation started while the last pieces were still being built, and the Netezza switch-off was in the plan from week one rather than left for a separate project.

What should be ready before week one?

Every gate at the insurer had a named signatory before the next phase could open. Scope creep showed up as a missing signature rather than a slipped date, and internal audit got its paper trail without anyone writing status decks after the fact.

What happens after cutover?

The insurer's team took over the running system on signed acceptance, with the converted schemas, lineage records, infrastructure as code and validation harness in hand. The policy slice started while claims was still stabilizing, paid for in part by the Netezza support contract that had just ended, and the Oracle license on policy administration became the budget line for the slice after that. Over three or four slices, the legacy estate shrinks on a schedule the CFO can plan around.

Real programs follow the same logic of funding the next step from the last one. At Synaptics, discovery that Aedeon ran in days freed budget for a smart-queue architecture on AWS for its chip-design clusters, which lifted throughput on one of its largest EDA clusters by up to 40%, and the operational data lake on AWS became the foundation the next initiative builds on.

How Should You Evaluate a Data Modernization Partner?

With four questions, which is how the insurer did it the second time around. Who carries the schedule risk? Who does the engineering? How will the new system be proven right before cutover, and when does the legacy one turn off? Logos and partner badges told it a little, and the answers to those four told it how delivery would go.

It learned to ask them the hard way. Its first program went to the proposal that looked safest on paper, with a large team and a long discovery phase, and the plan never named a date for Netezza. This time, its CIO took a scorecard like this one into every vendor meeting:

Why does the delivery model matter as much as the architecture?

The insurer saw why with its own two proposals. Both put roughly the same AWS design on the table, and the difference was in who would spend the hours. The first staffed people for discovery, mapping, validation and test generation, which is the repetitive work where timelines stretch and invoices grow.

An agent-native delivery model hands that repetitive work to agents and puts experienced engineers on architecture, judgment calls, and cutover. Those engineers stay embedded with your team until the system runs. As Gautham B, Forward-Deployed Engineer in our Data Engineering practice, writes in his piece on what a forward-deployed engineer does: "Go-live is the moment the real requirements arrive." Ask any prospective partner how long its engineers stay after cutover and what they own during that period.