6 Areas to Optimize Insurance Data Migration #
Analysis Phase (Project Planning/Determination of Conversion Approach)
1. Approach project as a business imperative, not an IT preference.
Business needs must drive most approach and planning decisions. Also, involve Actuarial, Compliance, Legal, Project/Internal Audit and Computer/IT Operations departments early in the project planning process particularly in relation to:
• General approach decisions
• Policyholder/agent impact assessments
• Balancing tolerances
• Scheduling decisions
2. Analyze utilization of historical data, and then determine history data requirements:
• How many backdated transactions are processed in a period
• Maximum and Average days back dated
• Frequency of reinstatement
• Time span between lapse and reinstatement
These metrics will drive smart fact-based decisions regarding the amount and types of historical data to be converted. In addition, these metrics will help determine how much history must be functional (support undo/redo) vs. view only history. Once the history requirements are determined, carefully consider conversion approach options: Current Date, Point in Time, Issue Date.
- Convert 2 years functional history per policy
- Convert all active policies and policies terminated in last 2 years
3. Issue new business on the target system
If applicable, beginning issuing new business on the target system 3-6 months prior to converting policies. This negates the need for automated conversion of new business data and stabilizes the target system.
4. Increase complexity of data conversion over time
Convert small volumes, simpler products first. Increase volumes and complexity as confidence, experience and processes improve.
5. Focus on utilization of best resources by task:
• Product SMEs -- Product Configuration
• Conversion SMEs -- Conversion Data Mapping
• Business Process SMEs -- Requirement Definition for Target System mods
• Target System SMEs -- Target System development, testing
6. Design a detailed policy level automated balancing process.
• Ideally, utilize an existing common extract such as an actuarial system or data warehouse extract to balance critical data elements at a policy level
• Discuss accuracy tolerances early and often.
7. Design conversion engine for reusability if conversion is multi-phased.
(Product Configuration, Target System Modifications, ETL development)
8. Some source system data cleanup will be required. Start cleanup tasks early. Monitor for steady progress.
9. Develop capability to adjust financial and compliance policy level values.
10. Focus on post conversion processing
If conversion approach is point-in-time or issue date, the conversion process will automatically test most business process. The conversion process is effectively a multi-year parallel test. Therefore, user testing should focus on “go forward” or post conversion processing. That is the conversion process is the ultimate automated test tool for most business functions, particularly financial processing.
11. Execute “dry runs” 1-2 weeks prior to production conversion.
Test communication, issue resolution and back out processes.
General Project Management
12. Secure and maintain support
Frequently review, restate and remind the conversion team and entire organization of project objectives focusing on benefits. Secure and “advertise” executive level project commitment.
13. Do not sweat the small stuff.
Look for simple, cost justifiable solutions to small problems.
14. Clearly define the escalation process
Utilize an effective issue resolution process including a well defined escalation process.
A simple and elegant, fully automated, single-technology solution
DCA generates the data migration code in the same language and technology used for I/O code. There is no unnecessary mix of technologies. This elegant solution is simple and requires fewer skill sets, fewer development environments and smaller teams. This minimizes communication paths, implementation hours and cost and ensures success.