When migrating to new instance, how to handle old data?

[Suggy]

Hello,

One of our customer has done many customizations in their existing instance. They want to move back to box. Hence they want to implement/start using a brand new instance.

Now the question is, what to do with old data? How to bring that to new instance (old instance had many custom fields).

If you have come across such scenario, please share inputs on how you have handled.

Thankyou...........

[Mark Roethof]

Hi there,

That's really a question for yourself. Do you want to take over old data? Or only tasks which are still active? Or handling those tasks on the old instance? Handling on the old instance, since their might be workflows/flows running which you cannot take over. What to do with CMDB? Locations? Etc..

If taking over old data, you simply need to go and map field to field, which custom (or legacy) fields needs to land where, or making a summary of all old fields and having that in the notes or in the description. Etc.

I have had projects like these in several shapes. Some indeed taking over old data, which just was a major extra effort and the actual gain very limited. I have also had projects just starting fresh on the new instance, and just handling the old tasks on the old instance which worked pretty well.

[AndersBGS]

Hi @Suggy ,

I would always recommend to start fresh on the new/OOTB instances instead of taking over old data.

this limit the effort a lot, and old tickets can be finished on the old instance while new tickets will be handled in the new instance.

If my answer has helped with your question, please mark my answer as accepted solution and give a thumb up.

Best regards

Anders

[Suggy]

Hi @Mark Roethof  @AndersBGS Thanks for your inputs. Yes, for exsiting ACTIVE tasks, we are asking them to close it in old instance and for newer ones create them in new instance.

But the customer is asking to somehow have the old data (Inc, prb, chg, request tabled with many custom fields) also stored in NEW instance for reference and audit purpose. 

Hence checking in community if anyone faced this and how you handled it 🙂

[Mark Roethof]

I would avoid doing so. Even if the customer asks, explain to them why not doing so and the alternative way. Because a customer has a requirement, doesn't make it a valid requirement that should be handled. No is also a good answer 🙂