A policy administration system implementation plan sets out how an insurer will configure the new system, connect it to billing, claims, agents and documents, move the in-force book onto it and retire the old one. The decision that shapes everything else is how the book moves. In a big-bang cut-over every policy moves on one weekend, most of them in the middle of their term. Converting on renewal moves each policy when it renews, wave by wave, so the conversion arrives with the renewal offer the customer was already going to receive. Botminds' Policy Data Conversion is built for the second approach: its agents convert and re-rate each wave against the legacy system and the wave goes live only when every policy ties out. This guide sets the two side by side, row by row, on the same book.
Two ways to move an in-force book, compared on the same policies
Big-bang cut-over: All at once, on a cut-over weekend; most policies are mid-term.
Convert on renewal, wave by wave: At its own renewal, in waves grouped by renewal month and line.
Big-bang cut-over: A mid-term change: new policy number, new documents, possibly a new premium they did not expect.
Convert on renewal, wave by wave: The renewal offer they were due anyway, produced by the new system.
Big-bang cut-over: Mid-term, where a coverage cut can count as a cancellation (Texas is one such state).
Convert on renewal, wave by wave: In the renewal offer, where the state’s renewal and change notices already apply, if the error is found first.
Big-bang cut-over: The whole book in one pass, against one deadline.
Convert on renewal, wave by wave: One renewal month at a time; rules learned on one wave carry to the next.
Big-bang cut-over: Roll back the whole book, or fix forward under pressure.
Convert on renewal, wave by wave: Hold back one wave; the policies stay on the legacy system and renew there.
Big-bang cut-over: Shortest overlap.
Convert on renewal, wave by wave: Roughly one renewal cycle of overlap, with the legacy book shrinking each month.
Big-bang cut-over: A single peak around cut-over.
Convert on renewal, wave by wave: A steady rhythm of test loads and sign-offs, wave after wave.
What goes into a policy administration system implementation plan?
At a minimum: milestones, a description of the work, and what happens to the legacy system. Those are the three elements GAO tests in federal modernization plans, drawn from government and industry practice: "(1) milestones to complete the modernization, (2) a description of the work necessary to modernize the system, and (3) details regarding the disposition of the legacy system" (GAO-25-107795, July 2025). Of the nine critical federal systems that had plans, "three included all three elements of a plan". Federal systems are an analogy for an insurer, not a measure of one, but the third element is the one insurance plans also tend to leave vague.
For a policy administration system, the description of the work needs a conversion section of its own: the waves, the map and who decides doubtful values, the test loads and parity measures, the notices each wave triggers, the policies that cannot convert, the sign-off order, and the cut-over and fallback for each wave. The full section list, with owners and evidence, is in the data migration plan template.
Until agencies fully document modernization plans for critical legacy IT systems, their modernization initiatives will have an increased likelihood of cost overruns, schedule delays, and overall project failure.
GAO-25-107795, on incomplete modernization plans
Why converting on renewal ties each policy to a notice it already owes
Because a renewal is already a regulated event with its own clock and its own notices, and a conversion that rides on it uses that machinery instead of creating a second, unplanned event. At renewal the insurer must send an offer, and if the renewal changes the premium or the coverage, many states require that change to be stated: Texas requires a notice of each material change on renewal at least 30 days ahead (Tex. Ins. Code §551.1055), and California requires the renewal offer to identify any reduction of limits or elimination of coverage (Cal. Ins. Code §678).
The discipline that follows is simple: a converted policy should renew with the same premium and coverage it would have had on the legacy system, at the same rates, unless the insurer has deliberately decided otherwise and sent the notice that decision requires. Converting on renewal makes that testable, because each wave can be re-rated against the legacy system before its offers leave. Whether a conversion counts as a renewal at all, or as something else, depends on what changes; that is the subject of renewal vs rewrite.
A big-bang cut-over moves policies in mid-term, where the rules are less forgiving. Texas, for example, counts an insurer as having cancelled a policy if, without the insured's consent, it reduces or restricts coverage by endorsement or other means (Tex. Ins. Code §551.103), and a cancellation has its own notice and permitted reasons. A conversion error that drops a coverage mid-term is a coverage cut the insurer never intended and never noticed.
When a big-bang cut-over still makes sense
A single cut-over is the right call when the overlap would cost more than the risk it removes. That is usually true in four situations: a small book that can be reconciled policy by policy in one pass; short-term or monthly policies, where renewals come round so fast that waves add little; a legacy platform that loses support before a renewal cycle could finish; and lines where every policy is moving to new products and forms anyway, so each renewal is a deliberate change with its own notices.
Bank regulators describe the mechanics of single-weekend conversions plainly: "conversions are scheduled on long weekends to allow additional time before affecting weekday business" (FFIEC IT Examination Handbook, 2024, written for banks). The weekend buys time for the load; it does not buy time for a policy-by-policy comparison of the whole book. If you choose a big bang, the comparison has to be finished before the weekend, on a frozen copy, and every change made after the freeze has to be converted again.
The policy administration system implementation process, wave by wave
On renewal, the process repeats per wave: freeze the wave's scope, convert and load it, re-rate every policy against the legacy system, trace and fix differences by cause, sign, and go live in time for the wave's renewal offers. The waves are planned around the renewal calendar and the lines of business, not around the size the project office would prefer.
Take a sample conversion, on fictional data, as it runs through Botminds' Policy Data Conversion. Larkhaven Mutual is moving 214,860 policies off HOMER, an in-house mainframe, in six waves: dwelling fire first, then three homeowners waves, then personal auto, then auto and umbrella. The small first waves teach the map; the large later ones reuse it.
Six conversion waves, sized by the renewal calendar
The waves are also where learning compounds. In the sample, wave 3's parity rose from 88.4% at test load 1 to 94.9% at test load 2, and to 97.94% once the first rule was approved at test load 3. Every approved rule moves the map to a new version that later waves inherit, so the 128-policy alarm-credit rule written for wave 3 is already in place when wave 4's 49,126 homeowners policies are first loaded.
The map is versioned, so every wave starts from what the last one learned
The plan's fixed dates come from state law, not the project office
Each wave has to go live early enough for its renewal offers to leave on time, and each state sets that time. The latest safe sign-off date for a wave is the earliest offer or notice deadline among its policies, less the time it takes to produce and mail the offers. A wave that spans states inherits the strictest clock among them.
Renewal and notice clocks that set a wave's latest go-live
| State and line | What must leave, and when | If it is late |
|---|---|---|
| Iowa, personal lines (Code §515.129C) | Renewal policy, offer to renew or notice of nonrenewal at least 60 days before the term ends (30 days until 2025) | The policy is extended on the same terms for another term, or until replaced |
| Nebraska, property, marine and liability (§44-522) | Written notice at least 60 days before cancellation or nonrenewal, stating the reason | The section sets the period, not the consequence; agree the treatment of a late notice with counsel |
| California, policies covered by §675 (§678) | Offer of renewal at least 45 days before expiration, naming any reduced limits or removed coverage; notice of nonrenewal at least 75 days before | The existing policy stays in force unchanged for 45 days from a late offer, or 75 days from a late nonrenewal notice |
| New York, personal lines (Ins. Law §3425) | Nonrenewal or conditional renewal notice 45 to 60 days before the period ends | The insured may renew on timely payment |
| New York, commercial lines (Ins. Law §3426) | Nonrenewal or conditional renewal notice 60 to 120 days before expiration | Coverage continues on expiring terms, at the lower of current and prior rates, for 60 days after a late notice |
| Texas, material change on renewal (§551.1055) | Notice of each material change at least 30 days before renewal; agents 30 days before the first renewal on the new form | Without the notice, the change loses the protection that keeps it from counting as a nonrenewal or cancellation |
| Florida, property and casualty other than auto, outside the residential rules (§627.4133(1)) | At least 45 days’ written notice of nonrenewal or of the renewal premium | Coverage remains in effect, at the same premium, until 45 days after the notice or until replaced |
Note the Iowa row. Until the end of 2024 the state's personal lines clock was 30 days; from 1 January 2025 it is 60. A plan written against the old rule now produces late offers, and a late offer in Iowa extends the old policy on its old terms. Every wave's dates should be recomputed from the current statute, not inherited from a previous programme's calendar.
Legacy system migration strategy: decide what happens to the old system on day one
The old system's end is part of the plan, not an afterthought, and it has three parts: how long it keeps running, what is archived, and what is destroyed. Under renewal waves the legacy system keeps renewing the policies that have not converted yet, including any held back from a wave, so it stays a live production system until the last wave signs. In the sample, 35 policies from wave 3 stayed on the legacy system because they could not convert without a person; each renews there, or is converted by hand at renewal.
After the last wave, the plan needs a disposition: which history is migrated, which is archived in a form that can still be read, which documents must be kept for how long, and when the system is switched off. Bank regulators' guidance lists the same choices, that data "could be migrated to the new system, archived, or a combination of the two" (FFIEC IT Examination Handbook, 2024). Why the history is hard to leave behind is explained in legacy policy administration systems.
Held back, not forced: policies that renew on the legacy system until they can convert
An insurance policy administration system (PAS) implementation framework: who decides what
A workable framework names one owner for each kind of decision, and keeps the decisions that change a customer's policy inside the insurer. Product owners decide any deliberate change of rates, forms or coverage, and compliance decides the notices it needs. The conversion lead decides how legacy values are converted, through rules approved one cause at a time. The forms specialist decides doubtful mappings and unreadable documents. Policy services owns the policies that cannot convert and the renewal offers. The programme manager signs each wave last.
The framework also separates two kinds of change that programmes tend to blur. A conversion rule changes how a policy is converted and must leave its premium and coverage where they were. A product change alters the premium or coverage on purpose and must carry its own notice. In the sample conversion the agents may draft the first kind and are barred from the second: they never change a premium, a rate or a coverage to make a policy match, and every comparison runs at the legacy rate version so a product change cannot hide inside a conversion result.
Policy administration system implementation plan template: what the document should hold
Whatever approach you choose, the plan document should let a reader find, for every wave, who decides, what is measured and what date nothing can move past. The checklist below is the outline; the plan template guide expands each item into the sections, owners and evidence of a working plan.
Ten things a policy administration system implementation plan must state
- The approach, by line
Big bang, renewal waves, or a mix, with the reason for each line of business.
- Milestones per wave
Freeze, test loads, sign-off and go-live, each computed back from the wave’s earliest offer deadline.
- The work, described
Mapping, document reading, re-rating, reconciling, rules and sign-off, with who does each.
- Acceptance measures
Per-policy and per-wave premium tolerances, and no tolerance on coverage.
- Rate version rule
Every comparison at the legacy rate version, so rate changes and conversion errors never mix.
- Notices each wave triggers
State by state: renewal offers, material change notices, agent notices, affiliate transfer notices.
- Policies that cannot convert
How they are found, who owns them, and how they renew on the legacy system.
- Sign-off order
Who signs each wave, in which order, from what evidence.
- Fallback per wave
How a wave is held back and renewed on the legacy system if it does not tie out.
- Disposition of the legacy system
What is migrated, archived, kept for how long and destroyed, and when the system is retired.
Questions people ask
What is the difference between a big-bang and a phased policy conversion?
A big bang moves every in-force policy at one cut-over, usually mid-term; a phased conversion moves groups of policies in waves, and for policy systems the natural phase is the renewal month. The trade is a short overlap against a smaller, reversible risk in each wave.
Can policies be converted mid-term?
Yes, but every difference the conversion creates then lands mid-term. In Texas, a mid-term reduction of coverage without the insured's consent counts as a cancellation, with its own notice rules. Converting at renewal places any intended change under the renewal notice rules instead.
What should a data migration strategy document contain?
The approach and its reasons, the waves and their dates, the mapping and decision rules, the acceptance measures, the notices, the handling of policies that cannot convert, the sign-off order, the fallback and the legacy disposition. GAO's minimum for any modernization plan is milestones, a description of the work and the disposition of the legacy system.
How many waves should a policy conversion have?
As many as the renewal calendar and the lines of business suggest, with the first wave small enough to learn from. The sample conversion uses six, starting with 9,804 dwelling fire policies and ending with 48,780 auto and umbrella policies.
How long does each conversion wave take?
Long enough for its test loads plus a margin before its renewal offers. Botminds estimates one convert, load and compare cycle at 22 working days by hand and five with agents comparing every policy; a wave typically needs more than one cycle, and in the sample wave 3 took three test loads.