Leaving a Hosted ELT Service in a Regulated Insurer: What the First 30 Days Look Like

This is an illustrative engagement built from the problems insurers bring to us, not a customer story. Revoluzen publishes no customer names until they agree to be named.

The situation

A mid-size general insurer runs its policy and claims systems on-premises, its finance system in a vendor cloud, and its reporting on a hosted ELT service that copies all of it into a cloud warehouse every night. Three things have gone wrong at once:

• The bill. The ELT service charges by rows synced. Claims volume rose, a new product line launched, and the invoice doubled in a year. The data team has started leaving tables out to contain it.
• Residency. The regulator's guidance now expects policyholder data to stay in-country. The ELT service stages data in a region the insurer did not choose and cannot see.
• Evidence. An internal audit asked which inputs produced last year's reserve figure. The answer took three weeks and ended in a reconstruction, because the pipeline had changed and the logs had rotated.

The data team is four people. They are competent and busy. They cannot stop reporting for a quarter to rebuild it.

Week 1: assess

A Revoluzen engineer works with the team for five days. The deliverable is a written plan, and it is priced as a fixed assessment.

Inventory. Eleven source systems, of which three carry policyholder data. Forty-two pipelines on the hosted service, of which nineteen feed reports anyone still reads. The others are left behind on purpose.

Architecture review. Residency is met by construction: Revoluzen Flow Enterprise runs on the insurer's own servers, so no data leaves the network at all, and no vendor holds a copy. The evidence requirement is met by signed execution receipts from Revoluzen Evidence, which an auditor can verify offline.

Proof of concept. One real pipeline, the claims extract, rebuilt on the open-source build against the production replica. Row counts match the hosted service's output to the row. The engineer notes two connector maturity flags for the team to check before the migration proper.

The plan. Nineteen pipelines in three waves, both systems running until each wave's outputs match, the hosted service cancelled after wave three. Scope, sequence and the two limits found are written down.

Weeks 2 and 3: implement and migrate

Installation. Flow Enterprise on one production server with a Postgres metastore and the insurer's identity provider in front, plus a development environment, which is free under the license. This is the Quick Start package.

Wave one: the five claims pipelines. Each is rebuilt as a verified build: an agreed specification, tests, one revision round, documented handover. The policy database connector exists in the catalog; the claims system needs a custom connector for its REST API, delivered as a versioned extension on the upgrade path. The data team watches the first two and builds the next three themselves with the engineer reviewing.

Evidence from day one. Every run of the new pipelines emits a signed receipt covering inputs, outputs, code version and result. The reserve calculation now has a record that outlives any log.

Wave two: finance and reporting. The dashboards move to Revoluzen Studio, where every figure traces to a defined metric. The two definitions of "earned premium" that had been living in different dashboards become one.

Week 4: enable and cut over

Two days of training for the four engineers and two analysts; a security and compliance walkthrough for the insurer's reviewers and the internal auditor; runbooks for day two. The production promotion path is set up so that a pipeline change needs a reviewable diff and an approval before it takes effect.

Wave three, the remaining reporting pipelines, is done by the insurer's own team in the following month with a priority support plan behind them. The hosted service is cancelled when the last output matches.

What it cost, and what changed

The first year's license plus services comes to a fraction of the previous year's hosted bill, and the number no longer rises with claims volume. Policyholder data never leaves the insurer's network. The reserve figure has a signed receipt the auditor can verify without asking anyone. And the team that could not stop for a quarter never did: the longest they spent away from their normal work was the five days of the assessment.

The limits, stated

Flow Enterprise is self-hosted software under a commercial license; the insurer runs it and we support it. Connector maturity is published per connector, and the two flagged in the assessment were checked before anything was built on them. Revoluzen is a young company; the core is Apache-2.0 and cannot be taken back, receipts verify offline with a standalone tool, and source escrow for the commercial parts is part of the contract.

See data residency and sovereignty, replacing hosted ELT and the insurance page.

Frequently asked questions

How long does it take to leave a hosted ELT service?

For a team of this size with around twenty live pipelines, about a month to the first cut-over and a second month for the long tail, with both systems running until each pipeline's outputs match.

Does the data have to stop flowing during migration?

No. The hosted service keeps running until each migrated pipeline matches it. The cut-over is per pipeline, not a single switch.

What happens to the connectors we rely on?

Each is checked against the published maturity status before anything is built on it. A system without a catalog connector gets a custom connector as a versioned extension, priced at $499 for bounded interfaces.

Can our own team do the migration?

Yes, and in this scenario they did the third wave themselves. The services are designed to hand the work over, not to keep it.

Is this a real customer?

No. It is an illustrative engagement built from the problems insurers bring to us. Revoluzen publishes no customer names until they agree.