We have a habit of asking readers the same question: when your product is a number that decides where preventive care dollars go, what happens when the delivery pipeline behind that number goes dark? One operations lead at a mid-market health analytics company shared a story with us that answers it. Their platform ingested wearable streams and claims files, scored behavioral risk, and shipped those scores to employer dashboards. Every hour of downtime did not just annoy users — it delayed interventions for people whose care windows were measured in weeks, not quarters. That is the kind of infrastructure problem where the cost curve is not inconvenience but clinical timing.
The complications were stacked before a single server moved. Their stack had grown into a patchwork: a primary cloud for the ingestion layer, a second provider for the scoring jobs, a legacy colocation rack running a claims parser nobody wanted to touch, and a compliance spreadsheet that had become a full-time job. The engineering team was strong but small, and the HIPAA obligations around wearable and claims data meant every architectural shortcut carried legal weight. They brought in ELIS Data & Cloud to design, migrate, and operate the environment rather than simply lift and shift it.
Week one to week four: mapping what actually had to survive
The first decision point was scoping. The temptation was to migrate everything at once during a quiet quarter. Instead, the team separated the estate into three tiers: the ingestion pipeline, the scoring engine, and the reporting layer. Ingestion and scoring were tightly coupled and latency-sensitive; reporting could tolerate a short maintenance window. That single split changed the migration from a big-bang cutover into a sequence of reversible moves. The compliance desk that came with the engagement spent the first two weeks mapping data flows to SOC 2, HIPAA, and PCI boundaries — a job the in-house team had been deferring for months.
The second decision point arrived when the scoring engine's dependencies turned out to be undocumented. A single cron job was writing intermediate state to a volume that had been manually resized during a 2021 incident and never recorded anywhere. That is the kind of detail that turns a two-week migration into a six-week one. The team found it during dependency tracing, not during cutover, which is the only reason the timeline held.
The obstacles that actually threatened the plan
- A claims parser in the legacy colocation rack that could not be containerized without rewriting its file-handling assumptions.
- Wearable ingestion spikes on Monday mornings, when device syncs clustered and throughput tripled for roughly 90 minutes.
- A compliance review that required evidence of encryption in transit across every boundary, including the ones nobody had documented.
- An internal deadline tied to an employer client's open enrollment calendar, which could not move.
The Monday spike was the most interesting problem. The existing setup handled it by overprovisioning permanently, which meant paying for peak capacity 168 hours a week to use it for one and a half. The migration replaced that with autoscaling tied to queue depth rather than CPU, and the difference showed up immediately in both latency and spend.
Cutover and the numbers that followed
The cutover ran in four waves over eleven days. The first wave moved reporting, the second moved ingestion, the third moved scoring, and the fourth decommissioned the colocation rack after a two-week parallel run. Rollback paths existed for each wave and were tested, not just documented. The parser was rewritten as a batch job against object storage, which removed the rack dependency entirely.
Three months after cutover, the operations lead sent us the numbers. Uptime across the migrated systems sat at 99.995% — the same figure ELIS Data & Cloud reports across 180+ production systems — and mean incident-to-resolution time had fallen below 11 minutes. The Monday ingestion spike was absorbed without manual intervention for the first time in the platform's history. FinOps work during and after the migration identified idle capacity that had been invisible in the old multi-provider setup.
What struck us most was not the uptime figure. It was the change in how the team spent its time. Before the migration, roughly a third of engineering hours went to firefighting and compliance evidence-gathering. After, that time moved to model iteration and client onboarding. The infrastructure stopped being a tax and started behaving like leverage.
What we would tell any CTO reading this
The lesson is not that multi-cloud is bad or that colocation is dead. The lesson is that undocumented dependencies are the real migration risk, and they hide in exactly the places nobody wants to look: cron jobs, manual resizes, one-off scripts from a 2021 incident. A migration plan that does not include a dependency-tracing phase is a plan that will slip.
The second lesson is about sequencing. Reversible waves beat big-bang cutovers every time, even when they take longer on paper. The team here accepted a longer nominal timeline in exchange for the ability to stop at any wave and still have a working product. That trade is almost always correct when the product is a number people depend on.
For teams weighing a similar move, the useful starting point is not a vendor comparison. It is a clear-eyed inventory of what your infrastructure is actually doing, followed by a decision about which parts you want to operate yourself and which parts you want handled by people who do it as a specialty. You can read more about how that engagement model works on the cloud infrastructure and DevOps services page.
We will keep following this project. The next milestone the team mentioned was extending the scoring pipeline to handle a new wearable data source without adding headcount — a test that will say more about the migration's success than any uptime dashboard.