A data migration plan template should give every wave of the conversion the same seven sections: scope and calendar, the map and who decides, test loads and acceptance measures, notices, policies that cannot convert, sign-off and fallback, and what happens to the legacy system. For a policy conversion the plan is built backwards. Each wave's renewal offers have a legal deadline; the wave must be signed before the offers are produced, frozen before it is signed, and loaded and compared enough times before the freeze to find what is wrong. Everything else in the plan hangs off that calendar. Botminds' Policy Data Conversion is built to run a conversion that way, wave by wave on the renewal calendar, and the examples below come from a fictional sample conversion run through it.
Count back from the renewal date: one wave's calendar under a 60-day offer rule
- Three convert, load and compare cycles13 wk
- Freeze to offers, 1 week
- Offer to renewal: 60 days60 d
- Three cycles3 wk
- Freeze to offers, 1 week
- Offer to renewal: 60 days60 d
What should a data migration plan template contain for a policy conversion?
The seven sections below, repeated for each wave, with an owner and the evidence that closes each one. Bank regulators' guidance on system conversions describes the core of any conversion plan as "ensuring the capability of personnel to map existing entity systems and components to the new system, to identify interdependencies, and to transfer data to the new systems", and adds that "an after-action review of the conversion can be useful for minimizing potential issues in future conversions" (FFIEC IT Examination Handbook, 2024, written for banks). For an insurer, add what that general guidance does not cover: re-rating, coverage comparison and the notices each wave can trigger.
The data migration plan template: seven sections, one owner and one piece of evidence each
| Section | What it states | Owner | Evidence that closes it |
|---|---|---|---|
| 1. Scope and calendar | Waves by line, state and renewal month; for each wave the earliest offer deadline, the latest sign-off, the freeze and the test loads | Program manager | A dated calendar per wave, recomputed from current statutes |
| 2. The map and who decides | Products, forms, fields and code values; the confidence at which mappings approve on their own; who decides below it | Product and forms specialist | A versioned map with every decision and its approver |
| 3. Test loads and acceptance | Per-policy and per-wave premium tolerances, no tolerance on coverage, the rate version rule, the measures tied out | Conversion lead | A reconciliation per test load: counts, premium, every coverage, every differing policy by cause |
| 4. Notices | For each wave and state, the renewal offers due and any notice the conversion could trigger: material change, conditional renewal, premium explanation, transfer | Compliance with policy services | A notice list per wave, and confirmation that no unintended change reaches an offer |
| 5. Policies that cannot convert | How they are found, their reasons, owners and actions, and how they renew meanwhile | Policy services lead | A list of every held-back policy with its action and status |
| 6. Sign-off, cut-over and fallback | The signature order, what each signer attests, the go-live step, and how a wave is held back | Program manager | A signed tie-out with open items, owners and reasons |
| 7. Legacy disposition and records | What is migrated, archived and destroyed, retention periods, access tests and the switch-off date | Program manager with records and security | An archive plan tested for retrieval, and a disposal register for every extract |
Start from the renewal date and count back
Every wave has a renewal date range, and each state has a deadline for the renewal offer or notice before that date. Iowa's is: "At least sixty days before the end of the policy or contract term, an insurer shall mail or deliver to the last known address of the first named insured a renewal policy or contract, an offer to renew the current policy or contract, or a notice of nonrenewal" (Iowa Code §515.129C). It was 30 days until an amendment took effect on 1 January 2025 (2024 Iowa Acts, ch. 1032), so any calendar carried over from an earlier programme is now a month short.
Count back from the earliest renewal date in the wave: subtract the state's offer deadline, then the days needed to produce and mail the offers, then a freeze before which every rule is decided, then the test loads. If the wave spans states, use the strictest clock among them; Nebraska, for example, requires "sixty days' written notice prior to cancellation or nonrenewal" of property and liability policies (Neb. Rev. Stat. §44-522(2)). If the test loads do not fit, split the wave or start earlier; do not shorten the notice.
Section 1: scope, waves and the calendar
Group policies into waves by renewal month, line and state, and size the first wave to learn from. The sample conversion moves 214,860 policies in six waves, starting with 9,804 dwelling fire policies and ending with 48,780 auto and umbrella policies; wave 3 is 18,412 homeowners policies in Iowa and Nebraska renewing in December. For each wave the section records the earliest renewal date, the offer deadline in each state, the latest sign-off, the freeze and the planned test loads.
List also what the wave excludes: lines moving later, policies already held back, products that will not be offered on the new system. A wave's scope should be frozen as a list of policy numbers, so the reconciliation can count both ways against it.
Section 2: the map, and who decides each value
The map turns every legacy product, form, field and code value into its target in the new system, and the plan states who may approve which mapping. In the sample, the map at version 3.8 covers 9 products, 64 forms, 212 fields and 1,318 code values; values at 95% confidence or more approve on their own and the rest go to the product and forms specialist or the conversion lead by name. Every decision is versioned.
The plan should also say where the map gets evidence outside fields: which remarks are read, which scanned documents (declarations, endorsements, alarm and inspection certificates, appraisals), and what happens when a page cannot be read. In the sample wave, 12 of 41,206 scanned documents went to a person.
Section 3: test loads and acceptance measures
State in advance what a passing wave looks like, so nobody argues about it at the freeze. The sample uses $1.00 per policy as rounding, 0.01% of written premium for the wave, and no tolerance on coverage; every policy is re-rated at the legacy rate version, compared field by field and step by step, and every difference is grouped by cause with one rule per cause. What the reconciliation report must show at each test load is set out in the reconciliation report example.
Plan the number of test loads, and plan for one more. In the sample, wave 3 needed three: 88.4% of policies matched at the first, 94.9% at the second, and 97.94% after the first rule was approved at the third, with 344 policies still differing across five causes.
What a test load hands the plan: open causes, each with a drafted rule
Section 4: the notices each wave triggers
List, for each wave and each state, every notice that could be owed, and confirm before the freeze that the conversion triggers none it did not intend. If the conversion is a plain renewal by the same insurer, the only notice is the renewal offer itself. If the wave moves onto new forms with material changes, Texas requires notice to the insured and, separately, to the insurer's agents "not later than the 30th day before the earliest renewal date on which the new policy form is used" (Tex. Ins. Code §551.1055(d)). Transfers to an affiliate, conditional renewals and premium explanations each have their own rules.
The section's real job is to keep unintended changes off the notice list by keeping them out of the policies. Which events count as renewals and which do not is explained in renewal vs rewrite; the risks that turn into notices nobody planned are set out in data migration risks and mitigation.
Section 5: policies that cannot convert
Some policies will not convert without a person, and the plan should say in advance what happens to them: they stay on the legacy system and renew there until resolved. In the sample wave 35 did: 21 with no construction type, 9 whose ZIP did not match the county and 5 whose named insured had died with the estate pending. Each has an owner and one of three actions: request the data from the agent, correct the address, or convert by hand at renewal.
Section 5 in practice: every held-back policy with its reason and its action
Section 6: sign-off, cut-over and fallback
Name the signers, their order and what each attests. In the sample the conversion lead signs first, for the comparison and the rules; the policy services lead second, for the held-back policies and the offers; the program manager last, for the tie-out as a whole. The wave signs only when every policy ties out or each open item is accepted with a written reason and an owner, and coverage differences cannot be accepted at all.
Fallback is what makes converting on renewal safe: if a wave does not tie out by its latest sign-off date, its policies renew on the legacy system for one more term and the wave moves to a later slot. The plan should say who can make that call and by when, because it has to be made before offers are produced.
Section 7: the legacy system's disposition and records
The last section decides what happens to the old system after the last wave: which data is migrated, which is archived and for how long, which is destroyed, and when the system is switched off. Retention periods for policy records run for years after a term ends, so the archive must stay readable long after the people who knew the old system have moved on. The trade-offs are set out in the policy administration system implementation plan guide.
Data migration plan example: where one wave stands at its third test load
A plan is easier to judge with a live wave in it. Wave 3 of the sample conversion, at test load 3 and before any rule was approved, split as follows. One approved rule then fixed 128 policies, and the rest of the plan's work was the five remaining causes, the 39 coverage gaps among them, and the 35 held-back policies.
Wave 3 at test load 3: most policies match, and the plan is about the rest
18,412 policies
- Match to the cent · 95.6%
- Within $1 · 1.7%
- Differ · 2.5%
- Can’t convert · 0.2%
What generic data migration plan templates leave out
Most downloadable templates are written for moving records between databases, and they are good at the technical sections: environments, extract jobs, load sequence, cut-over runbook, rollback. Five things an insurance conversion needs are usually missing, and a plan copied from one of them will look complete while leaving the costliest risks unowned.
A re-rating step. Generic acceptance stops at row counts and control totals; a policy conversion has to re-rate every policy and compare it with the legacy premium. The rate version rule. Without it, a rate change taking effect during the programme and a conversion error look the same. Coverage compared by value. Generic templates count forms and endorsements; a schedule with its items missing still counts.A notice list. No general template knows that a wave's offers have a statutory deadline, or that a change in coverage at renewal can owe a notice of its own. A home for held-back policies. Generic plans treat records that fail to load as defects to clear before cut-over; in a renewal conversion they are policies that renew on the legacy system, with an owner, until they can move.
When you evaluate a vendor's or integrator's plan, check it against those five before anything else. Each one is a place where the plan should name a person and a piece of evidence, and each is a place where Botminds' Policy Data Conversion produces the evidence: every policy re-rated at the legacy rate version, every coverage compared, every difference tied to its cause, and every held-back policy listed with its action.
Data migration planning checklist
Before the first test load of each wave, the plan should be able to answer every item below. Most of them are dates and names, which is the point: a conversion plan fails on unowned decisions more often than on technology.
Data conversion checklist for each wave
- Earliest renewal date and every state’s offer deadline
Recomputed from the statutes in force today.
- Latest sign-off and freeze dates
Counted back from the offer deadline, with the mailing time.
- Scope frozen as a list of policies
So the reconciliation counts both ways.
- Map version and approval threshold
And who decides every value below it.
- Acceptance measures written down
Per-policy and per-wave premium tolerances; none on coverage.
- Rate version rule
Every comparison at the legacy rate version.
- Notice list per state
Including notices the conversion must not trigger.
- Held-back policies and their owners
With actions and how they renew meanwhile.
- Signers, order and fallback
Who can hold a wave back, and by when.
- After-action review
What the wave taught the map, for the next wave.
Questions people ask
Is there a data migration plan template in Word?
The seven-section table on this page is the template: copy its sections, owners and evidence column into a Word or spreadsheet document and add one calendar per wave. What matters is not the format but that every section has a named owner and a piece of evidence that closes it.
What is a data migration plan document?
It is the written plan for moving data from one system to another: scope, sequence, mapping, testing, acceptance, cut-over, fallback and decommissioning. For an insurance policy conversion it also has to cover re-rating, coverage comparison and the notices each wave can trigger.
How far ahead should a conversion wave be planned?
Far enough to fit the test loads, the freeze and the state's offer deadline before the earliest renewal in the wave. On Botminds' estimates and Iowa's 60-day rule, a wave compared by hand needs roughly 23 weeks from first test load to the first renewal, and about 13 with agents comparing every policy.
What is the difference between a data conversion checklist and a plan?
A checklist confirms that each wave is ready; the plan says how it gets ready, who decides and by when. Use the checklist at the start of each wave and at its freeze, and the plan to resolve whatever the checklist finds open.
Who writes the data migration plan?
The programme manager owns it, but its sections belong to the people who will sign them: the conversion lead for acceptance, the forms specialist for the map, policy services for held-back policies and offers, and compliance for notices.