This article is by Justin Goff, Director of Technical Delivery, Hylaine
With nearly two decades of experience spanning data architecture, data engineering, data science, advanced analytics and AI-driven solutions, Justin delivers scalable, real-world outcomes—helping clients turn complex data challenges into operational results that drive performance and growth.
Insurance organizations have talked about cloud transformation for years, yet many still rely on legacy systems, Fragmented data, and manual compliance processes that cannot keep pace with regulatory change.
Urgency has shifted. Federal policy changes in healthcare coverage, new CMS interoperability mandates, and the broader AI revolution are forcing every carrier to confront whether their data infrastructure can support what their competitors are already deploying. With U.S. insurance IT spending projected at $173 billion in 2026 and 91% of banks and insurers actively migrating to the cloud, the question is not whether to move, but how to move well. The challenge is no longer strategy, now it’s execution.
1. Unification, not migration
The most persistent misconception in cloud data work is that it is a lift-and-shift exercise. Move the bits, point the connections to the new environment, and you’re done. This dramatically understates the complexity. Data in legacy systems is both stored and understood differently. A field that means one thing in a legacy claims adjudication system can mean something entirely different in the cloud platform that consumes it.
For example, at a Fortune 25 managed care organization, legacy claims data lived across multiple on-prem stores and SaaS platforms with overlapping and conflicting records. The data had to land in the cloud in a form that satisfied both the new application and existing compliance and auditing regulations. It did not need to look identical to the legacy version, but it had to mean the same thing in a way that could be validated and traced. That is unification, and where most cloud data programs underestimate the work.
1. The readiness gap
The market is loud about AI readiness, and rightly so. Most organizations that struggle with AI are failing because their data foundation was not built with AI in mind. Lineage cannot be traced from source to destination. Personally Identifiable Information (PII) protection and compliance validation are still manual. Demographic drift accumulates silently across decades of fragmented sources. Basic entities like “policyholder” or “claim” are defined inconsistently across teams. For each one of these execution problems, there is an execution answer.
Unifying and scaling insurance operations in the cloud starts with a strong foundation of governance and reliability, followed by a 3-phase approach:
1. Phase 1: Strategic planning
Execution starts with a focused form of strategy to define the effort and produce decisions teams can act on quickly.
Priority number one is creating a documented governance strategy that defines data ownership, quality standards, lineage requirements, PII protection rules, and the AI readiness criteria future workloads will inherit. Next is enablement planning to translate the governance strategy into a working playbook with a 90-day sprint plan that creates initial momentum and a 12-month roadmap that ensures early efforts connect to broader priorities.
The non-negotiable constraint is that use cases get prioritized by measurable ROI, not enthusiasm. Cloud data unification is a multi-year program, and the only way to retain executive sponsorship across that horizon is to demonstrate measurable results along the way.
1. Phase 2: Technical standards and automation through templates
Once governance is set, the work shifts to defining technical standards including DevOps and CI/CD pipelines, identity and access management, infrastructure as code (IaC), security assessment protocols, cost tagging, and data platform conventions. Defining standards is half the battle. Making them easy to follow is the other half, and that is where most organizations leak velocity.
For a Fortune 25 insurance company, we partnered with the team to build IaC templates that pre-configured cost optimization tagging, security group configurations, IAM policies, and monitoring integrations. When a team needed to spin up a new application or data source, they used the template. Tags were applied automatically. Security policies were inherited by default. Teams did not need to know how it worked under the hood. It was built into the deployment package.
The same principle extends to database configurations, Kubernetes deployments, pipeline scaffolding, and monitoring dashboards. Two payoffs follow from this approach. Time-to-value accelerates because teams stop reinventing deployment patterns. Long-term manageability improves because the resulting infrastructure is consistent and well-documented, avoiding the Snowflake deployments nobody fully understands and nobody wants to touch.
1. Phase 3: Enablement at scale
Standards only matter if teams adopt them. Different teams bring different levels of technical maturity. Some move quickly, while others need more support. A dedicated enablement team helps bridge that gap. In practice, engagement tends to take three forms:
Advisory. For technically mature teams with their own development resources, the enablement team provides architecture review and best-practice coaching. The adopting team does the work.
Advisory plus hands-on. For teams with partial gaps in IaC, security configuration, or pipeline development, the enablement team supplements with targeted implementation support.
Fully hands-on. For business-oriented teams that lack development resources entirely, the enablement team handles the full build, from deployment through monitoring.
Regardless of tier, every team works from the same templates and governance framework. That is what keeps the organization consistent across very different maturity levels. After the build, ownership transfers through training, documentation, and a structured handoff. For teams without capacity to manage production operations, a managed services model can fill the gap.
1. Unification without consolidation
One execution pattern deserves a closer look. The persistent assumption is that data unification requires consolidating everything into a single repository. In insurance, that is often neither feasible nor desirable due to compliance and security requirements.
A federated architecture solves this. At the same Fortune 25 managed care organization, we helped build a federated data science platform with Databricks as the centralized compute layer. Individual teams kept their own isolated cloud accounts for transactional data, with their own access controls. A Mosaic AI gateway connected Azure and AWS for secure access to proprietary foundation models within a fully walled-off environment. Databricks federated query connections, paired with Unity Catalog for lineage tracking, gave the organization a unified analytics and AI layer across its full data landscape. For complex, regulated environments, this is not a compromise. It is the right architecture.
1. Where to start
With FHIR R4 deadlines in 2027, six-month Medicaid redeterminations already in motion, and CMS interoperability requirements exposing data quality issues that have been papered over for years, carriers with executable foundations will respond rapidly. The ones without will be building the airplane while flying it.
An honest assessment across the four dimensions of governance maturity, infrastructure standardization, enablement capacity, and end-to-end auditability can be completed in weeks and gives you the baseline to prioritize a phased roadmap. Strategy gets you to the starting line. Execution gets you across the finish.
Be the first to comment