Data MigrationData Migration focuses on the actual processes involved in exporting data from a legacy system to a new data store i.e. new system. The key stages involved in a successful data migration include;
Most of the time, these phases are not followed in a sequential stepped approach as data migration projects require more of an incremental and iterative approach. For example, data profiling will be carried out as a result of a month end mini migration and this process may uncover new values in the data that might require cleansing and will need mapping.
The precise methods used for any particular system depends entirely on the systems involved and the type, quantity and quality of the data being migrated.
At Insurance Data Migrations we have specialised in performing data migrations in the insurance sector for over 20 years and have developed a tried and tested migration methodology.
Our experience covers migrating data for Insurance Companies, Brokers & Software Houses. Projects have varied in size from one line of business to multi-site / multi-system migrations that have transferred millions of records.
We have expertise in all lines of business from Private Car & Household to large Commercial Risks with Schedules of Insurance attached. On many occasions we have been asked to perform migrations where a companies business is being split, due to commercial or technical reasons. This approach requires great care in the mapping and the merging of data, but our experience in this area will ensure your data is migrated cleanly and efficiently.
This experience has also enabled us to develop a detailed understanding of both the functionality business users are exposed to and how the underlying processes work. This in-depth knowldge of insurance data and its relationships enables us to give a very thorough service which is second to none.
We pride ourselves in the amount and quality of the data that we typically migrate. A recent instance was a Motor Fleet Migration for a leading Lloyds Insurer which consisted of clients, policies, risks, certificates, endorsements, vehicles, claims and financial transactions dating back to 1993.
We are experts in migrating from different legacy systems which can include relational database, ISAM file structures, documents, either from recognised word processors such as MS Word or text editors, spreadsheets and text files.
Data Migration Project PlanningA data migration project is traditionally part of a larger transition project. At Insurance Data Migrations we recommend that the migration is thought through as part of the system selection process. Failure to do this may result in the migration being compromised or even very difficult to complete. Please click here for information on business and system analysis and data profiling phases which are stages in project planning phase.
In any successful project planning stage engagement with the business is vital in order to gather information on data stores and business processes and establish business and mapping rules. Good communication between the project team and the business is neecessary to install confidence, motivation and coordination between team members, business users and the wider network of key stakeholders including the various business experts i.e. Actuaries, Operations Specialists, Compliance and Legal Staff, Finance and Stats Dept., IT staff, Testers etc.
Insurance Data Migrations can also offer advice on the amount of historical data which is typically migrated and in answering questions such as:
Should we bring all or part of the data? If just part, which parts? - based on renewal date of policy or data the claim was created? Should we filter specific data? Are our desired criteria extractable from the existing database? Are the desired fields of data importable into the new system? etc...
It is also at this stage where we can help you consider the different options available in terms of:
Data Migration StrategyOnce the decisions have been made regarding what to migrate, a migration strategy will be developed. Which strategy we recommend will depend on factors like budget constraints, resources available, amount of data to be migrated and project deadlines.
The Migration Strategy will include the findings from the data and system analysis, necessary cleansing requirements, mapping rules a detailed plan containing all the steps of the migration, the businesses rules and expectations, which techniques and tools are going to be used, the resource profiling and the testing and checking techniques.
Data Migration MappingData Mapping is the process which specifically identifies fields from the legacy system which need mapping to fields in the target system. Data mapping ensures the data fits and makes sense in the new system. Simple examples are things like the risk classes and brokers / intermediaries on your legacy system, these will need mapping to the new values held on your target system. More complex examples may be where the legacy systems held the policy sections as a free format text string, the migration may take this string for each policy and create the relevant sections underneath the policy on the target system.
Data Migration DevelopmentThis is when the extraction and transformation of data takes place and all the data manipulations are carried out in accordance with business rules. We have experience in using ETL tools such as SSIS, we also have experience of writing custom modules using technologies such as SQL scripting or CLR’s in C# in addition to traditional languages such as Dibol and Cobol.
Each method has its own benefits it depends on the demands of your particular migration. Quite often a migration may be made up of both ETL tools and custom modules. Which ever method is chosen the modules will include the business, mapping and cleansing rules that where defined in earlier stages.
Early Data ConversionNaturally the users of your legacy system may be resistant to change. During the development stage we use a phased approach showing your users incremental results which help in setting their minds at rest. For example once client development is complete we will migrate and showcase to business users the data successfully working in the target system. This is usually done through workshops and on a one to one basis with key stakeholders. This is then repeated for policies, claims, accounts etc. This phased approach helps fine tune each migration and delivers more accurate results in a quicker timeframe due to the data being seen early. Considering one increment at a time reduces risk and delivers value earlier providing opportunities for feedback and if necessary reworking so that the final release meets the business users real requirements.
Month End Mini Data MigrationsThrough out a migration project as part of legacy system month end routines we will also carry out mini migrations of all the data. This approach ensures that any new values or trends in the legacy data can be identified and any new issues can be resolved early. It also usually means that come the live migration you have comfort in knowing that numerous end to end migrations have been completed successfully.
Data Migration TestingTesting & Checking are often not given enough attention and time in mainstream projects and data migration projects are no different. The following tests are necessary after every release of the migration:
Using electronic check lists populated with sample data from the legacy systems the data migrated will be checked against the legacy system.
User Acceptance Tests carried out by the business users will also ensure the target system performs as expected once with the migration data has been loaded. It is quite often the data you can’t see on screen that causes problems in migrations, things like flags and counts. Click here for further information on Migration Testing.
Live Data MigrationWe have experience of delivering different types of data migrations. To ensure the least amount of disruption to the business it may be that all data is migrated over a long weekend and the old system is switched off except for viewing. Alternatively, the legacy system and target system may run in parallel for a period of time. We also have experience in performing incremental data migrations where data may be migrated over a period of a few months or even a year, usually using policy renewal date or something similar. Each option has both advantages and disadvantages in terms of costs and complexities.
A Comprehensive Audit TrailOnce all the analysis, development and testing stages are complete we would hand over sign off documentation which would detail the migration at both a business and technical level. This would include:
Data Migration Specification DocumentThis document is created during the data and system analysis stages and is used as a technical reference guide which explains what has been migrated at a field by field level. It gives a list of source fields from the legacy system against corresponding fields of the target system. Where there is no comparable source field it may just show a default value. Mapping may be included in this document or held in separate excel spreadsheets and referred to.
Data Migration Reconciliation DocumentsThese contain control totals for each part of the migration. They detail simple things like number of clients, policies and also give evidence of more complex things like the value of your accounts by risk on a year by year basis.
Sign Off Data Migration DocumentThis document is aimed at the business user and there is no technical detail. It contains a section for each area of the migration including all details of transformations that were used, any data quality rules and details of any records that were excluded. It also contains a description of the logic used (i.e. business rules) to get the data from the old to the new system. It should be signed off by each area of the business prior to go-live. (I.e. Policy Administration, Stats, Claims etc.)
The above documents will provide a comprehensive audit trail of the migration process and will give you full piece of mind that your migration is complete.
|
|
||
 |
||
|
|
||