What switching your operation to Regure actually involves
Not a multi-year overhaul. Regure replaces your legacy policy, claims and bordereaux operation one book at a time: configured from your own documents, tested on cases your team already knows, migrated with reconciliation, then the old workflow is retired.
The short answer
Switching to Regure does not mean switching everything off on a Friday and hoping on Monday. You choose a first slice of the business, usually one product, binder or renewal cohort. We configure it in Regure from your own product documents, rate tables, wordings and bordereaux formats, test it against cases your underwriters and claims handlers already know the answers to, move the data that slice needs, and cut it over once it meets acceptance criteria your business owner signs. Then the legacy workflow for that slice is retired, and the next slice starts from a platform that is already working.
Regure handles the move. Our team does the configuration, the data migration and the work of keeping your old system up to date while a slice moves. Your team supplies the material and checks the results. The old system is switched off for each slice as soon as that slice is accepted, so you are never running two systems for longer than the move itself takes.
A focused first scope, such as a single line of business without historical data migration, can be operational in as little as 14 days. Larger scopes are planned in the proposal, with the timeline set out there rather than promised before anyone has seen your book.
The point of going in slices is to control risk, not to keep two systems running forever. Every slice has a destination, a reconciliation method and a retirement date. When the last slice moves, the operation runs on one platform: policy, rating, claims, documents, commissions, bordereaux and the audit trail on the same record. For the strategic case for replacing legacy systems, see insurance modernization; this page is about how the work itself gets done.
Five steps from first conversation to a retired legacy workflow
The same sequence repeats for every slice. The first one takes the longest because it establishes the platform; later slices reuse it.
Bring one real book
A working session on something representative: one binder and one redacted bordereau, a product and its rate table, or a renewal pack. It exposes the product complexity, data dependencies and exceptions that a requirements list hides.
Scope the first slice
We agree which product, binder or cohort moves first, which route it takes, what data it needs and what “accepted” means. The proposal fixes the configuration scope and sets out the timeline.
Configure and test
Products, rating, documents, authority rules, workflows and bordereaux templates are configured from your material, then tested against quotes, endorsements and claims your team already knows the right answer to.
Migrate and rehearse
Data the slice needs is mapped and moved in rehearsals, reconciled with control totals and sampled field by field and document by document until the numbers agree.
Cut over and retire
Users and integrations move once the acceptance criteria are met and signed. Exceptions are closed, required history preserved, and the legacy workflow for that slice is decommissioned.
Your team decides what correct looks like
Nobody knows your book better than the underwriters, handlers and operations people who run it. Testing against cases they already know the answers to is how a configuration earns their trust before it carries live business.
What we need from you, and what we do
Implementation is a shared piece of work with a clear split. Your team brings the knowledge of how the business is written; our implementation team turns it into configuration.
From your team
- Product documentation, rate tables and wordings for the slice that moves first
- Binder or binding authority terms, including referral triggers and claims authority
- Your current bordereaux formats for each capacity provider
- Test cases with known answers: quotes, endorsements, renewals and claims
- A named business owner who signs off acceptance for each slice
- Access to the source data the slice needs, for mapping and rehearsal
From Regure
- Configuration of products, rating, documents, roles, authority rules and workflows
- Bordereaux templates per capacity provider, set up with the product rather than after the first deadline
- Integrations by REST API and webhooks to the systems that stay, such as finance or a data warehouse
- Data mapping, migration rehearsals and reconciliation evidence
- Cutover planning, decision thresholds and the agreed rollback approach
- Deployment on US or Swiss / EU infrastructure, chosen for your data residency
Two ways a slice moves onto Regure
Most operations use both: renewal-led for books where history can run off, in-force migration where it cannot. The route is chosen per slice, not once for the whole programme.
| Dimension | Renewal-led | In-force migration |
|---|---|---|
| What moves | New business and renewals for the slice are written in Regure from an agreed date | The in-force policies and open claims for the slice move to Regure on the cutover date |
| Legacy system's role | Runs off the expiring in-force book, then is retired for that slice | Retired for that slice at cutover, once reconciliation is accepted |
| Historical data migration | Limited to what the operation actually needs | Data mapping, reconciliation checks and cutover date are part of the configuration scope |
| Good fit | Annual books where a renewal cycle is an acceptable transition window | Books with long tails, open claims or a hard deadline to leave the legacy system |
| Ends with | Regure as the system of record for the slice, and the legacy workflow decommissioned | |
For a carrier-grade view of migrating a legacy policy administration system, including data and product reconstruction, see the legacy PAS migration playbook.
Replacing your system without a complete overhaul
The question we hear most is some version of: we know the current system is holding us back, but we cannot stop the business to replace it. That is a fair worry. The big-bang replacement programmes that gave core system projects their reputation tried to move every product, every record and every user on one date, after a long build nobody could test against the real book until the end.
Slicing changes that. The first slice is small enough to configure and prove quickly, and it is proved on your business, not a demo dataset. The people who will run it test it against cases they already understand. Cutover happens when the evidence says it is ready, not when the project plan says it should be, and there is an agreed way back if a threshold is missed. Each slice that moves takes its manual work, its spreadsheets and its legacy workflow with it.
What slicing is not is a way to bolt a new tool onto an old core and live with both. That is how most operations ended up with the fragmented estate they want to leave. The destination is one platform carrying the policy, the claim, the money, the documents and the evidence on one record, which is what makes a delegated authority audit a report rather than a project.
Find out what your first slice would be
Bring one binder and one redacted bordereau, or one product and its rate table. We'll show it configured in Regure and map what moving that slice would involve.
How data moves, and how you know it moved correctly
Migration is where replacement projects usually go wrong, so it is where the controls are heaviest.
Decide what moves
Active and service-relevant history moves into the operating record. Archive-only history can stay in a governed, searchable retention store. The split follows operational, regulatory and legal need, not what is easiest to copy.
Rebuild products as configuration
Products are reconstructed as versioned configuration covering eligibility, coverage, limits, rates, referrals, documents and workflow. Representative historical and new-business scenarios are recalculated and approved before cutover.
Prove it reconciles
Repeatable migration rehearsals, source-to-target control totals, field and document sampling and lifecycle testing produce the evidence your business owner signs against.
- Named business sign-off for every slice, against acceptance criteria agreed up front
- Cutover decision thresholds agreed before the cutover date, not on it
- An agreed rollback approach if a threshold is missed
- Every migrated record and every post-cutover action written to the immutable audit trail
The second slice is easier than the first
Once the first slice is live, the platform, the integrations, the roles and the reporting are in place. The next product or binder is a configuration exercise on a working system: a new rate table, new wordings, new authority rules and a new bordereaux template, tested the same way. That is also how new programmes launch after the migration is over. Adding capacity becomes a matter of configuring the binder rather than waiting on a development release. See how configuration works.
Today our implementation team does that configuration with you, and we are progressively opening the same configuration surface to customer implementation managers, so later products can be added by your own team.
What determines the timeline and the cost
Because products, rates, documents and workflows are configuration, the timeline is driven by the scope you choose rather than by custom development. The things that lengthen it are predictable: the number of products and capacity providers in the slice, how complex the rating is, whether in-force policies and open claims must move, how many systems stay connected, and whether you need dedicated or region-specific infrastructure.
Cost follows the same logic: a platform fee set by the modules you run, the number of products and the workload; a one-time configuration scope; infrastructure where dedicated deployment or data residency is required; and optional custom development or integrations. The configuration scope for your first slice is fixed in the proposal. See pricing for how the components fit together.
Implementation questions
Do we have to replace everything at once?
No. Replacement moves one coherent slice at a time: a product, a programme, a binder, an entity or a renewal cohort. Each slice is configured, tested, migrated and accepted, and the legacy workflow for that slice is retired before the next one moves. The business keeps writing throughout; what it never does is run two operating models indefinitely.
How long does implementation take?
It depends on the scope you choose. A focused first scope, such as a single line of business without historical data migration, can be operational in as little as 14 days. Broader scopes covering multiple products, configurable rating, commissions, portals, multiple entities, historical data migration or regional data residency are scoped to the operation, and the timeline is set out in the proposal rather than promised up front.
What does our team have to do?
Provide the material that defines how you write business today: product documentation, rate tables, wordings, binder terms and your current bordereaux formats. Supply test cases your underwriters and claims handlers already know the answers to, and name a business owner for each scope who signs off acceptance. Our implementation team does the configuration with you.
What happens to our historical policy and claims data?
Active and service-relevant history is migrated into the operating record. Archive-only history can remain in a governed, searchable retention store. The split is decided on operational, regulatory and legal need. With a renewal-led route, historical migration is limited to what the operation actually needs, because the in-force book runs off on the legacy system.
How is migration risk controlled?
Through repeatable migration rehearsals, source-to-target control totals, field and document sampling, lifecycle testing against real scenarios, named business sign-off, agreed cutover decision thresholds and an agreed rollback approach. A scope is not cut over until its acceptance criteria are met.
Can our own team configure Regure after go-live?
Products, rate tables, documents, roles and workflows are configuration, not code, so a later product is a configuration exercise rather than a development project. Today our implementation team does that configuration with you, and we are progressively opening the same configuration surface to customer implementation managers.
What does implementation cost?
Regure is priced as a platform fee, a one-time configuration scope, infrastructure where dedicated deployment or data residency is required, and optional custom development or integrations. The configuration scope is fixed in the proposal for the slice you start with, so the first phase has a defined cost before you commit.
Start with one book, not a programme
Bring one binder and one bordereau, or one product and its rate table. We'll configure it with you and show what moving that slice onto Regure involves.