Core Admin System Conversion Three Weeks Before Go-Live
A mutual insurer plans to move 120,000 life and annuity policies from a 25-year-old legacy administration system to a new platform on October 1. The final parallel run reconciles 99.1% of premium records and 98.6% of beneficiary records; the project target is 99.5% for both. The discrepancies include 1,080 policies with premium mode or modal amount differences and 1,680 policies with missing or mismatched beneficiary designations. Year-end processing starts November 15, and the vendor's next available conversion window is April. The project sponsor argues that 0.9% and 1.4% are small and that cleanup can happen after go-live. The operations VP notes that beneficiary errors could delay death claims, and premium errors could trigger improper lapse notices. The board wants a go/no-go recommendation with conditions.
1. Should operations recommend proceeding on October 1? Explain the trade-offs and state the minimum conditions for any go-live.
Read the worked answer
Operations should not recommend an unconditional October 1 go-live. The percentages look small, but they translate into 1,080 premium discrepancies and 1,680 beneficiary discrepancies. Those are not cosmetic fields. Premium errors can produce incorrect billing, grace-period notices, lapses, reinstatement requests, and regulatory complaints. Beneficiary errors can delay death claims and create legal disputes among claimants.
The trade-off is real: delaying to April creates cost, extends dual-system support, and may affect year-end work. But going live with unresolved beneficiary data and premium data transfers risk into production, where corrections are harder because staff may lose easy access to the legacy system and audit trails become more complex.
The minimum conditions for any October go-live should be:
- A complete policy-level exception list, not just an aggregate reconciliation percentage.
- 100% resolution or a documented manual workaround for beneficiary discrepancies, especially missing designations.
- A validated correction plan for every premium-mode and modal-amount discrepancy.
- A tested rollback plan and a freeze on nonessential changes.
- Adequate operations staffing for dual running and manual workarounds through year-end.
- Formal sign-off by operations, compliance, finance, and internal audit.
If those conditions cannot be met, a delay or a phased conversion by clean product population is safer than a broad go-live.
2. Outline a remediation and contingency plan for the discrepancies.
Read the worked answer
The plan should start with segmentation. Beneficiary discrepancies should be separated into missing designations, mismatched names or relationships, duplicate beneficiaries, and percentage allocations that do not sum to 100%. Premium discrepancies should be separated into mode, modal amount, billing date, and rate or benefit differences. Each category needs an owner, a correction method, and a validation test.
Beneficiary corrections should be prioritized because they affect claims. Missing designations may require policyholder contact or default beneficiary rules under the contract. Name mismatches need documentary support. Premium corrections should be applied through controlled scripts with before-and-after samples, followed by a second parallel run focused on the corrected populations.
Contingency planning should include a rollback decision point, a data freeze, a command center, and a manual processing queue for unresolved policies. If the company proceeds, it should not decommission the legacy system until reconciliation stabilizes. It should also prepare policyholder communications for any billing changes and a claims protocol so that beneficiary issues are escalated rather than discovered at the time of a death claim. The plan should be time-bound and reported weekly to the board.
3. How should the project sponsor's argument that cleanup can happen after go-live be evaluated?
Read the worked answer
The sponsor is treating the conversion as a technology event, but it is an operations event. After go-live, the legacy system may be read-only or decommissioned, subject-matter experts may be reassigned, and the new system's audit trail may not show the original source values clearly. Corrections then become detective work rather than controlled remediation.
Cleanup after go-live also competes with ordinary production work and year-end processing. If a premium error causes an improper lapse notice, the company may have to reinstate a policy, restore benefits, and respond to a complaint before it can even determine the full error population. A beneficiary error may not surface until a claim, when the policyholder can no longer clarify intent.
The sponsor is right that not every discrepancy must be fixed before go-live. Low-risk formatting differences or historical notes may be acceptable with a documented exception. But the sponsor's argument fails for financial and beneficiary fields because those errors create customer harm and regulatory exposure. The board should ask for a policy-level risk assessment, not a single percentage, and should require evidence that post-go-live cleanup has capacity, ownership, and a deadline before accepting it as a contingency.