Planning your Migration

Introduction

All migration projects are different, but many face similar challenges. Some forward planning of what needs to be migrated and identification of specific mapping challenges early in the process will save time later. Below is a high-level process that can be followed

Specific Guidelines

Here are some further guidelines for planning and executing your migration

• Planning: Identify the applications that need to be migrated and the tables within these that will need to be populated (on the target)
• Identify Projects: In general, it is best to migrate each application (e.g. Incident, Change, Knowledge etc) with a separate project. See if there is a Precision Bridge template that can be used as a basis for the migration of each application.
• Identify configuration/foundation data: As part of the migration of application data, you may need to also migrate configuration data such as users, group categorization etc.
• Identify complex mappings: If you are migrating complex data values such as knowledge articles, workflow etc, it may not be possible to fully automate the migration process using Precision Bridge. There may be manual work involved.
• Form / Field Mappings: For each application, Put together a spreadsheet detailing which tables and fields need to be populated on the target. Check that the required data on the source is all going to be migrated. For each target field, note any general mapping issues that might be faced (such as different values, different references (for fields that hold an id to a related record which will be different on the target)
• Key Mappings: Identify the key target fields for each target form. These should not include the id field, unless this can be set from the source data. In some cases, it may be simplest to add a custom field on the target form to store the id of the source record.
• Source Filtering: Identify what the top level tables in the application are and what filtering for each should be used. For records related to a 'Parent' plan use Inclusion Filtering.
• Live or Closed Tickets? For cross platform projects where workflow is used, it is highly recommended to migrate tickets/tasks that have been closed rather than attempting to migrate a live ticket. It will be very difficult to restart the ticket at the same point in its lifecycle and workflow. For intra platform migrations (for example Service Now to Service Now) this task is easier.
• Customisations: If customisations need to be made to the target tables or fields, maybe to hold source data that will not 'fit ' into OTB fields, perform these before starting the migration. The best practice is to try and keep the target as out of the box as possible. If custom fields must be used on the target, add these to the field mapping plan. One option with custom fields on source tickets that you would like to retain is to concatenate the values with the description field to avoid the need to customise the target while still retaining the source data.
• Build out the Projects: Precision Bridge templates should be used where available. Customise the template as needed, setting the required source filtering, add custom field mappings and update existing field mappings to match the spreadsheet created earlier.
• Test the Project Execution: Test each project with a small number of records using a QA / Development server. Run the projects in the correct order, so that any configuration/foundation records are migrated first. Check the target records generated, paying close attention to fields that store references to other records (e.g users). Confirm that any related records are correctly migrated and associated with the parent. Don't forget to check the attachments.
• Develop-Test-Develop cycle: Rework your project, testing each change with a small number of records until you are satisfied that the requirements have been met.
• Test with a larger data set: This test may be with all source records, or may be with a larger subset. The purpose of this test is to get an idea of how long the migration will take. If performance is seen to be an issue, or if you get timeouts occurring some changes will need to be made, either on the servers themselves (e.g. increasing timeout limits or adding indexes) or in Precision Bridge (e.g. Performance Tuning) This process should give you a good idea as to how much downtime you might need during cutover.
• Cutover Plan: Decide whether to conduct the entire migration during a period of downtime, or migrate the bulk of the records before cutover and run a delta migration to pick up recent changes only. If you are migrating to a greenfield server/instance it is recommended to migrate the bulk of records ahead of time, perform quality checks and then just migrate the changes (delta) during the cutover period. One option to minimise disruption is to run both systems concurrently for some time, with new tickets being created on the new (target) platform and old tickets being closed out on the old platform. This will need a regular 'delta' migration to keep the target system up to date.
• Post Migration: Precision Bridge can also be used to fix any specific issues raised by users post cutover.