Skip to content
All resources

Your system is being retired. What to ask before you migrate an open cover

“A tugboat guiding a fully loaded container ship stacked high with shipping containers”

In June 2025, Applied Systems announced it was withdrawing Applied Epic from the UK broker management system market, committing to what it described as a multi-year transition. No end-of-support date has been published, and Applied TAM and other products continue in the UK.

So there is no countdown clock. What there is, for brokers using it, is a decision that now has to be made on your timetable rather than deferred indefinitely. That is worth treating as an opportunity, because a migration you plan is a substantially different exercise from a migration you are forced into.

It is also worth saying that this is not only an Epic question. Systems get retired, acquired, repriced and deprioritised all the time, and every broker will face this eventually.

Why specialty migration is not a data volume problem

The standard migration conversation is about records. How many clients, how many policies, how many documents, how long.

For a cargo or transport book that is the easy part. The hard part is relational.

An open cover written four years ago is still live. Hanging off it are hundreds of declarations, several mid-term adjustments, a coinsurance split, and bordereaux that went to carriers referencing specific consignments. The commercial reality of that cover is not in any single record. It is in the relationships between them.

Migrate the records and lose the relationships and you get a system that contains your history but cannot use it. Everything still reconciles on paper. Nothing reconciles automatically. Six months later somebody is maintaining a spreadsheet to bridge the gap, which is precisely what you were migrating away from.

Five questions for any vendor, including us

What happens to the link between a cover and its declarations? You want the answer to describe a relationship being migrated, not two tables being loaded.

Will you stage it by country, or is this a single cutover? A single cutover across several jurisdictions means every tax, currency and regulatory difference has to be right on the same weekend.

How long do we run in parallel? For a declaration book, the honest answer covers at least one full adjustment cycle, because that is the first moment you find out whether the history actually works.

What have you migrated before that looks like our book, and what have you not? A vendor willing to say plainly what they have not done is giving you better information than one who has done everything.

And what is in scope versus chargeable? Migration is where implementation budgets quietly double. Get the boundary in writing.

What a good answer sounds like

Scoped after seeing the data, not before. Staged rather than big-bang. Parallel running with a defined exit test rather than a date. And a named person who owns it on the vendor side.

Anyone quoting a fixed timeline for a book they have not examined is quoting a licence sale, not a migration.

Where we sit

We scope migration per customer as part of onboarding, because a cargo book with years of declaration history is not a fixed-price exercise. tigerlab BMS holds open cover, declarations, adjustments and bordereaux as structured records, which is what makes the relationship migration possible in the first place. Built with a global cargo brokerage, first markets live, rolling out across more than 30 countries.

Running a shortlist? Download The migration diligence checklist: twelve questions to put to every vendor, with notes on what a weak answer sounds like.