Transitioning to fresh instance - any tips and lessons learned?

[Pall Sigurdsson]

Is there anyone here in the community who has been involved in a transitioning from an old customized ServiceNow instance to a fresh instance and doing some business transformation at the same time (such as switching from service portal to employee center, from pure ITSM to CSM+ITSM) and who can share a few tips or lessons learned, for example about ...

• Go-live strategy: Did you go for a phased approach or big bang, why and how did it work out? Did you have to decide what to do with open incidents, running projects, running workflows (catalog, change request etc.) in the source instance at the time of go-live of the new one? How did you handle replies to notification emails which originated in the old/source instance?
• Migration technology: Did you for example use import sets, export sets, instance data replication, 3rd party tool?
• Governance: What are the most important roles and what skills are needed for success in such a project?
• Organizational change management: How to make the organization ready for the transformation, how to approach training etc.

[Daniel Draes · Accepted solution]

Yeah.. kind of. Helped a few customers at least to decide wether they should do a greenfield approach or not.

The essence of it is basically that a fresh instance is like a completely new product. The only benefit is that both are ServiceNow based you you do (mostly) not need to train the admin crew again. But since you do a transformation of the processes (like ITSM -> CSM+ITSM), you will have to change the way you work. This it not any different than if you would change from say Remedy to ServiceNow. Two completely different processes on two different platforms.

Keep that in mind...  it kind of forces you to rethink certain things. Like data migration: Would you migrate data from Remedy to ServiceNow? If so... which and why? Most of the time we would not recommend due to the huge data mapping effort required. Same will apply to your change. Like from Incident to Case, or from customized changed to baseline, ... the changes will be impacting and hence a migration most of the times makes no sense for transactional data. A bit different for master data or foundation. Foundation (users, groups, deparments, etc) are imported anyway, so reuse (but still revisit) the integration and get it from source. No need to migrate.

Master Data... is data authored in the existing ServiceNow. Maybe some CI attributes? These will need to be migrated for sure.

As for governance, there is a reason why you are where you are (highly customized). To make sure you do not repeat ending up there a strong governance is key. Make sure you define simple but powerful rules to make sure you stay as close as possible to the baseline. I have seen customers proclaim like a zero-customization Strategy, meaning any touching of baseline objects needs to go through an architecture review sometimes involving the CIO for approval. This stops a lot of discussions 😄

[Daniel Draes]

Oh.. saved to quickly 😄
Are you in IMPACT customer? If so, Impact has great team members who can help you through that - namely the success and platform architect. Success architect focused on organizational topics and platform architect ... well, on the platform 😄

[Pall Sigurdsson]

Many thanks for your answer, @Daniel Draes . It's very helpful to get these points. No, we are not an IMPACT customer - at least not yet but we have been and are still looking into that option.

Our main arguments for having some of the existing transactional data available in the new instance are:
1. Our B2B customers are currently able to access both open and closed cases (in the form of incident records) on the customer portal (service portal adapted to external customers). Ideally we would like them not to lose that ability.
2. Some tasks are long-running and we will not be able to keep our old instance alive long enough for them to finish. Here we are talking about tasks such as projects, demands, ideas, problems, stories and epics. Projects would be especially difficult to close and re-create manually from scratch in the new instance. With the new data model that comes with CSM, we want to have ongoing and new projects for external customers defined as customer projects.
3. Sometimes the proof that something was done or agreed is in the comments of old incidents, project tasks etc.

There are other drivers for keeping data accessible, such as legal obligations with regards to data retention, but that will not necessarily require it to be stored in the instance. When deciding where to store the data we decide/are required to store, ease of compliance with (European) privacy regulations becomes yet another factor.

We have very little foundation data authored in the ServiceNow instance. Most of the data is coming in via imports from other systems. That includes our CMDB and data related to customer contracts, which we need to fit into the CSM foundation data model, which is another challenge. Because foundational data often has interrelations (such as user-group, company-domain etc.) as well as relations to the transactional data that we want to move, we cannot just turn on the integrations from the respective sources in the new instance. We need to have the corresponding records with same sys-IDs and therefore we need to first import the data from our old instance.

The main reason why our old instance is heavily customized is that we have been using it from the beginning to support external customers but the ServiceNow product that is intended for that (CSM) didn't exist at that time. Some of the deviations from baseline throughout the years were a real business-necessity but not all. With increase maturity we have been reverting some of the changes made back to baseline in the last years, which is helping us in the transition now. We are also looking to tighten the governance by setting up a demand board. I really like your idea about the touching of baseline objects needing CIO approval 😊