ESM Migration – Moving Custom Content Guidance
Getting ready to transition legacy solutions, including current ServiceNow instances – ServiceNow Paris, Quebec, Rome, San Diego and Tokyo? You’re not alone. Enterprises that are looking to drive digital transformation across business applications often realize it’s the best way to improve agility, performance and save cost and effort.
However, migration to ServiceNow can be tedious due to lack of implementation expertise or knowledge gaps within the current staff and service providers. This series of blogs will share global transition experience from platform owners, outsourcing transition experts and architects across technical, solution and platform to help Enterprise Service Management (ESM) Platform owners, sourcing advisors and contract negotiators gain practical insights to simplify the migration process. There is a lot to cover, so this post is divided into six parts.
Lets’ Start
This is part 1 and will provide considerations for migrating legacy code and data into out-of-the-box (OOTB) ServiceNow tables. Current licensing for ServiceNow restricts the number of custom tables that can be created. Custom tables lead to more testing and possible impact when upgrading ServiceNow. New capabilities are added twice a year – each release may allow custom work to be replaced by out-of-box capabilities. Alcor has experience assessing legacy systems and in the ServiceNow data schema including the Common Service Data Model now at version 3.0
Alcor has migrated legacy transaction and foundation (user, company, groups) data into ServiceNow many times. However, Alcor does not recommended this approach. It is difficult to retain legacy relationships i.e. CI records, group records, user records, and previously submitted incidents from inactive employees. A strong consideration should be given to a Greenfield implementation where only active data is brought into the ServiceNow instance (such as that discovered by tools or that is loaded as new records for only open transactions)
Consider the following to 1) minimize the effort and 2) maximize the business value of moving any code or data from a legacy system into a new fresh installation on the latest version (major release) of ServiceNow.
The actual effort will depend on the amount of customization and technical debt in current tables; client production ServiceNow instance field name changes, choice list modifications, new fields, field data type changes, and field format. The full effort will include exporting the data and then configuring the import into ServiceNow. Most often the System Import utility will be used which may require pre- and post- import scripts in addition to a transform map along with small sample tests to assure success. See “Import Sets” in docs.servicenow.com to learn more.
If all data is migrated this may include importing data that has no business use such as records
1) past the data retention period
2) closed tickets
3) configuration items (CIs) no longer being used
If OOTB tables are loaded with transaction records from other systems this may require addressing systemIDs to assure they are unique and using legacy data types which may differ from the previous system. Global Unique Identifier (GUID) often must be retained or synchronized with ServiceNow identifiers making the import data mapping a larger effort.
Migrating to OOTB tables will require about 75% more effort than migrating the data to custom tables. This is based on actual experience migrating the following tables of data from existing ServiceNow legacy production instance into tables in a new out-of-the-box (OOTB) ServiceNow production instance.
If all records including users, groups, CIs, categories and choice lists in the client instances are brought into the new ServiceNow production instance this effort will increase. Finally, the assumption is made that CI relationships will not be migrated but rather discovered by tools integrated with the new ServiceNow instance.
Greenfield Definition – A project that lacks constraints imposed by prior work. The analogy is to construction on new land where there is no need to work within the constraints of existing buildings or infrastructure. In software development, a greenfield project is started on a new fresh install of the latest software on the latest infrastructure and the SDLC is progress by cloning up from Dev to UAT to Production only until the first Go Live. All integrations are established new to this greenfield SDLC set.
It’s Time to Get Going!
In this blog, we determined what to do with the solution design and data in legacy tools especially when the desired state is to migrating into a new ServiceNow production instance.
Next in this series, we will consider:
Part 2 – Migrating into an existing ServiceNow instance
Part 3 – Migrating record history including comments
Part 4 – Migrating legacy system date to an external data source
Part 5 – Impact of Moving Data from One Table to a Different Table
Part 6 – Audit considerations
Contact Alcor Solutions, Inc. at information@alcortech.com for Managed Services for your ServiceNow-centric Platform, Multi-Vendor Management, Service Reliability or more targeted advisory services, implementation, and operational support. Alcor can accelerate or augment your efforts to fully utilize ServiceNow as the center of a powerful corporate platform. How are you progressing? Provide us your own experience, questions and comments below.
About The Author:
Brent J Knipfer is a Chief Architect at Alcor Solutions, Inc.
ServiceNow Platform Architect since 2009
Remedy Solution Architect since 1998
Global Service Transition Manager
Global Service Desk, CMDB and Service Catalog Product Manager
20+ Years of Solution Design and Outsource Migration Experience.
Back to Blog
