Back to Box - Re-implementation in a Fresh ServiceNow Instance

[anithanarayan]

Hi Team,

Please provide your valuable suggestions from your past experience of executing something similar. I am sure we would have gone through these same set of questions with several ServiceNow customers.

Many Thanks in Advance. 

Background - Customer has a current instance (Dev, Test & Prod) which has been customized heavily, multiple platform owners, service providers etc. resulting in challenges in ongoing support, manageability, upgradeability and building any new enhancements.

Solution - The plan is to do a Fresh Out of the Box Implementation in a New Instance.

Continue with existing Prod instance and minimal Support for it (Incident & Basic Request Management) until the New Instance goes live.

Questions -

1. For the Fresh Implementation, how many new instances to be procured (Prod & Non-Prod) ?  Would they be charged ? 

My Opinion - Buy 2 new instances (1 Non Prod & 1 Prod) + Utilize the existing Test Instance after zboot. 

So for the Fresh implementation, we would have 2 Non-Prod (Dev & Test) and 1 Prod instances.

And For the existing Prod instance, we manage with just 1 Non-Prod instance

2. Please propose the best Solution for Data Migration. 

My Opinion - No Data Migration since old data would have all customized data elements which we want to eliminate.

OR

Consider 1 Year data for migration with Out of the box fields only (Incident, problem, change)

Please provide suggestions for Request Data Migration (REQ, RITM & sctask). I see this as challenging since catalogs shall vary from old to New.

3. What Data Archival Mechanism to be adopted.

My Opinion - Once New Production is gone-live, Discontinue access to Old Prod for all End Users. Close all open tickets.

Clone the old Production instance to a Non-Prod instance and make it read only with limited access for all future references. Old Production instance decommissioned.

[Mark Manders]

1. Depends on how long this is going to take. I think in the end you need 4 instances: DEV-TEST-PROD and old instance for audit purposes. While implementing you need two instances: development and validation. Since you want to deploy, the second one should be a PROD instance (I think). And yes: they will have to pay, although you could reach out to ServiceNow with timelines to see what they can do. 

2. Depends on what your clients wants. Do they want old data to be able to report? Or do they want a clean instance and don't they care about what happened in the past? In case of data migration: every ticket has a requestor/caller, a short description and description and close notes/code. Map those to the new records (or set default values if it's just for reporting). 
All open data needs to be migrated. Make sure that things in a flow are migrated correctly (you don't want a change to get stuck, because you don't have certain data in the old instance, that you do need in the new).

Create export sets of active and inactive data and load them into the new instance through transform maps, making sure you gave everything needed.

3. I would just make the old PROD inactive (lockout/inactivate all users, except the ones that need to access it) and have ServiceNow make it a non prod instance, so payment is only due for 1 production instance after that. Here also: contact ServiceNow for this. It could very well be that they have a 're implementation package' ready.