A legacy policy administration system is the old core system that issues, rates, endorses and renews an insurer's policies, typically a mainframe or early client-server application built decades ago and kept running because the in-force book still lives on it. Legacy policy administration systems are hard to leave for a reason that has little to do with their age: over the years, the information that decides a policy's premium and coverage spread out of their fields into free-text remarks, code values whose meaning only a few people remember, and scanned forms attached to the policy. Moving the data is a technical job. Proving that every policy is still the same policy on a new system is the hard one, and it is what Botminds' Policy Data Conversion does: its agents read the legacy data and the scans, re-rate every policy in the new system and trace each difference to its source, for people to decide.
How old the oldest systems are: federal evidence, as an analogy
60 yrs
age of the oldest of the 11 federal systems GAO found most in need of modernization
Ages ranged from 23 to 60 years
8 of 11
of those systems use outdated languages such as COBOL and assembly
4 have unsupported hardware or software
80%
of federal IT spending typically goes on operating and maintaining existing systems
Of more than $100 billion a year
What is a legacy policy administration system?
A legacy system is one that still does essential work but is costly or risky to change, usually because of its age, its technology or the shrinking number of people who understand it. GAO's reviews of federal legacy systems list the symptoms: outdated programming languages, unsupported hardware and software, known security weaknesses that cannot be fixed without modernizing, and rising costs to keep them running (GAO-25-107795).
A legacy policy administration system adds an insurance-specific symptom: its data describes contracts that are still in force. A legacy reporting system can be switched off once its reports are rebuilt; a legacy policy system cannot be retired until every policy on it has renewed somewhere else. In the fictional sample conversion used throughout this series, Larkhaven Mutual's policy system, HOMER, is an in-house mainframe in service since 1994, with 214,860 in-force policies on it when the conversion starts.
How old are legacy systems? The federal evidence
The best public evidence on system age comes from the federal government, and it is used here as an analogy. Asked for their three legacy systems most in need of modernization, 24 agencies supplied 69; GAO ranked them and named the 11 most critical, ranging from 23 to 60 years old (GAO-25-107795). Two belong to the Treasury and run on COBOL and assembly language. A decade earlier GAO had described the Treasury's Individual Master File, the authoritative record of individual taxpayers, as about 56 years old and "written in assembly language code—a low-level computer code that is difficult to write and maintain", with "no firm date" for its replacement (GAO-16-468).
Ages of the 11 federal systems GAO judged most in need of modernization
What systems do insurance companies use?
A property and casualty insurer typically runs a handful of core systems around the policy: one that administers the policy, one that bills it, one that handles its claims, plus rating, document production and the connections to agents and brokers. In older estates several of these live inside one mainframe application; in newer ones they are separate systems connected to each other. Either way the policy administration system is the hub: the others read the policy from it.
Insurance core systems, and what each needs from the policy system
| Core system | What it does | What it takes from the policy system |
|---|---|---|
| Policy administration (PAS) | Quotes, issues, endorses, renews and cancels policies; holds products and forms | It is the source: coverages, forms, endorsements, terms and history |
| Rating | Calculates premium from the filed rates and rules | Every rating input on the policy, at the right rate version |
| Billing | Invoices, collects, refunds and cancels for nonpayment | Premium, term, payment plan, mortgagees and payers |
| Claims | Records and settles losses | The coverage in force on the date of loss, limits, deductibles and schedules |
| Documents | Produces declarations, endorsements, offers and notices | Everything printed on the policy and the dates notices are due |
| Agent and customer access | Lets producers and insureds see and change policies | Current coverage, premium and documents |
How the book got stuck: four ways rating left the fields
A legacy policy system is rarely stuck because its data is lost. It is stuck because much of the meaning is no longer where a new system would look for it. Four patterns recur, and the sample conversion shows each one.
Remarks. When a product needed an input the record layout had no field for, it went into free text. In the sample, the protective device field holds only Y; the alarm type that earns a 1% credit sits in the remark CS ALM SOUTHGATE MON #77412 CERT REC 03/19. Scans. Forms and certificates were attached as images: the alarm certificate itself, roof inspection reports, appraisals, and scheduled personal property endorsements whose items were never keyed. Codes that lost their meaning. A roof stored as an age class, a deductible stored in dollars, a territory code later split in two: each was right when it was set up and needs interpretation now. Defaults. Missing values were filled at some point with something that let the transaction pass, and some policies have no construction type at all.
None of these is a defect in the old system. The old system rated these policies correctly for years, because its programs and its people knew where to look. The new system does not, and the conversion is the moment that knowledge has to be written down.
What a legacy policy looks like from the inside
The scanned page is part of the policy
For a regulator, the policy is not just what the system holds; it is what the file shows. The NAIC's model rule on market conduct records expects a policy file to show "the policy period, basis for rating and any imposition of additional exclusions from or exceptions to coverage", and to keep the material needed to rebuild how the policy was rated (NAIC Model Regulation #910).
Any guidelines, manuals or other information necessary for the reconstruction of the rating, underwriting, policy owner service and claims handling of the policy.
NAIC Market Conduct Record Retention and Production Model Regulation #910, §5.B(4)
If a credit rests on a certificate, the certificate is part of the basis for rating, and a conversion that keeps the field but loses the page has lost part of the policy. In the sample wave the agents read 41,206 scanned documents for 18,412 policies: declarations, endorsements, alarm and sprinkler certificates, inspection reports and appraisals. The few that changed a premium or a coverage are the reason the scans cannot be skipped.
A rating input that lives on paper
What decades of maintenance cost
Keeping a legacy system alive gets more expensive as it ages, and the cost crowds out its replacement. GAO notes that federal agencies have typically reported spending about 80 percent of their IT budget on operating and maintaining existing systems, and that relying on COBOL and assembly code brings "a rise in procurement and operating costs, and fewer individuals with the proper skill sets" (GAO-25-107795). COBOL, GAO adds, "was introduced in 1959" and "became the first widely used, high-level programming language for business applications".
For an insurer the most expensive part of that cost is often invisible on a budget: the knowledge of what each code and remark means, held by the people who have run the system longest. When they retire, the meaning goes with them, and the conversion has to recover it from the data and the scans. That is a strong reason to convert while they are still there to confirm what the agents propose. The cost side of the decision is worked through in policy administration system replacement cost.
Why proving the policy is harder than moving the record
Moving a record copies its values; proving a policy shows that a different system, reading those values through its own products, forms and rating, arrives at the same coverage and premium. The second needs everything the legacy system knew implicitly to be made explicit, one value at a time. In the sample, the map that does that covers 9 products, 64 forms, 212 fields and 1,318 code values.
The knowledge a conversion has to make explicit
What the legacy system knew: Y, with the type in a remark and on a certificate; its rating program knew to apply the credit.
What the new system needs to be told: A device type, such as central station fire and burglary, to apply a 1% credit.
What the legacy system knew: An age class.
What the new system needs to be told: A roof year; without it, the year the house was built.
What the legacy system knew: A dollar amount.
What the new system needs to be told: A percentage, which a careless map rounds.
What the legacy system knew: One code for a ZIP code.
What the new system needs to be told: One of two territories, by address.
What the legacy system knew: A schedule premium; the items on a scanned endorsement.
What the new system needs to be told: Each item, with its class and value.
What the legacy system knew: A count.
What the new system needs to be told: A start date it can count from.
This is why the work does not shrink with better load tools. What shrinks it is reading the remarks and scans systematically, comparing every converted policy at the legacy rate version, and turning each kind of difference into one decision. How that differs from an ordinary data migration is the subject of data conversion vs data migration, and what to look for in software that claims to do it is in the insurance data migration tool guide.
Leaving without losing history
The last step of leaving a legacy policy system is the one most often deferred: deciding what happens to its history. Policies that have converted still have past terms that only the old system can show, and examiners, courts and customers can ask about them for years. Bank regulators' guidance on retiring systems makes a point that applies equally to insurers: "effective entities have a process in place to periodically validate the accessibility of archived data" (FFIEC IT Examination Handbook, 2024).
In practice that means an archive that holds the old terms, the scanned documents and the rating manuals and code tables needed to read them, tested from time to time by someone retrieving a real policy, and kept for the longest retention period that applies. The retention rules themselves are covered in data migration risks and mitigation.
Where Botminds' Policy Data Conversion fits
It is for the step between the legacy system and the new one. Six agents read the legacy extracts, remarks and scanned documents, propose the map with a confidence, convert and re-rate every policy at the legacy rate version, group differences by cause and draft one rule per cause, and tie out each wave on count, premium and every coverage. They are read-only on the legacy system and never change a premium, a rate or a coverage to force a match. People approve every rule, decide every doubtful mapping and sign every wave.
Questions people ask
What is a policy administration system (PAS)?
It is the core insurance system that quotes, issues, endorses, renews and cancels policies and holds their products, forms and history. Billing, claims, documents and agent portals all read the policy from it, which is why replacing it touches every other core system.
Why do insurers still run legacy policy systems?
Because the in-force book lives on them, and a policy system cannot be retired until every policy has renewed somewhere else and been proved the same. GAO's federal reviews show the same pattern on a larger scale: critical systems 23 to 60 years old, most of them still waiting for complete modernization plans.
What languages are legacy policy administration systems written in?
Mainframe-era business systems were often written in COBOL, which GAO calls the first widely used high-level language for business applications, sometimes with assembly language, and store data in fixed record layouts. GAO found eight of the eleven most critical federal legacy systems still used outdated languages such as these in 2025.
Can a legacy policy system be kept as an archive?
It can, but a running mainframe is an expensive archive. The alternative is to migrate closed terms, scans and the rating manuals and code tables needed to read them into an archive that cannot be altered, then test retrieval from time to time; what matters is that every past term can still be produced as it was.
How long does it take to leave a legacy policy administration system?
At least one renewal cycle if policies convert on renewal, plus the time to configure the new system before the first wave and to archive the old one after the last. In the sample conversion, six waves renew from October to March.