Few major business systems meet all of the organization’s requirements “out of the box” (OOTB). Most companies have specialized business processes that aren’t supported by the native ERP, CRM, or service management software, and custom add-ons must be developed and tested to satisfy these needs.
Over time, a business system can become bloated with customizations. Some custom features have to be reworked or expanded, and others are abandoned because of shifting processes, priorities, or business strategy.
A system migration project from one instance of a business system to another represents an opportunity to clean house, start fresh, and maximize the use of the software’s OOTB feature set. But too many organizations executing such a migration fall into the trap of trying to replicate every customization in the target system.
Disadvantages of Migrating Customizations
The reasons to avoid re-creating your customizations include, among others, the following:
Most business software is designed to support commonly accepted best practices. If your organization isn’t using these best practices, you’d better have a compelling reason. Hint: “Because we’ve always done it this way” is not a compelling reason.
Because of changes in system architecture or database design, customizations created for an older instance might not work in a new instance. In this situation, developers would need to rebuild the customizations from scratch, adding to the timeline and expense of the migration project.
In many cases, functionality that required a customization in the old instance is supported OOTB in the new instance, eliminating the need for the customization at all.
Bottom line: Attempting to replicate customizations adds time, expense, and complexity to a migration project that is complex enough already and may needlessly perpetuate business processes that are not best practices.
“But…We Really Need This One!”
That said, there are times when reproducing a customization is unavoidable. Sometimes there is a reasonable method to the madness of an organization’s peculiar business practices—they are more efficient, for example, or they fit the business model better. Whatever the case, a business system can have customizations that the business can’t live without.
If you find yourself in that situation, make sure you know what you’re getting into and how to make the transition as smooth as possible:
Work with your software vendor, system integrator, or implementation partner to analyze the customization and see whether there is partial or complete support for the functionality in the new instance.
Account for any new development work in your project plan and budget.
Don’t forget about the data. Customizations often involve custom database tables and fields. These must be migrated along with the custom code.
For ServiceNow migrations, the best way to handle the migration of custom data objects is to use the Instance Migrator from Precision Bridge.
Instance Migrator and Migrating Customizations
For those ServiceNow customizations that you must migrate to a new ServiceNow instance, the Instance Migrator tool can be a lifesaver. With this tool, custom fields in the old instance can be concatenated and mapped to native fields such as notes or description in the new instance, if they are available. If no usable native fields are available, new custom fields and tables can be created in the new instance and mapped in the same way. This simplifies the data migration process for customizations, saving time and money.
If you’re faced with the need to migrate ServiceNow customizations to a new instance, contact Precision Bridge today to learn more about the Instance Migrator tool and schedule a demo.