SPM Teamspace1 Activation starting from customized SPM environment

[DianaPelaga]

Hi,

one of our customer developed the Demand and PPM processes before the Orlando version. At that time Teamspaces were not available yet, therefore the personalizations/customizations were done on the basis tables (dmn_demand, pm_project, ...) and on the original Business Rules,Script Includes,...

The customer wants to re-design the process starting from a completely OOTB environment, but with the need of using the 2 processes (old and new) in parallel for a certain period of time.

Is there any best practice to follow in this situation?

• Best practice to restore ootb
• Best practice to implement the solution considering for example:

archiving the old data and activate only teamspace 1 for the new demand restoring ootb in the basis tables VS restoring ootb on the basis tables and activating 2 Teamspaces (Teamspace1 with the migrated data from the old process and Teamspace 2 with the new process)

Thanks in advance for feedbacks

[phil_bool_unifi]

I've solved this problem previously.  When you stand up the teamspaces, changes made to the dictionary will cascade to the new child records, so you'll see that additional dictionary records are present.  You should only need to remove these from the form.  Meanwhile, any custom UI Actions, business rules, client scripts etc.  will need their conditions updating so they only run when current.sys_class_name == "tsp1_project".  It takes a bit of time, but it's good to have an OOB PDI next to you, so you can compare.

However you choose to proceed, this isn't the crisis it may seem.  Careful testing, and comparison to OOB is the key.

[DianaPelaga]

That's exactly the approach we were thinking to adopt.

If you faced the same context, did you move the old data to Teamspace 1 end developed the new process on the 2nd? Or just let the old stay on the basis and activate tsp1 for the new?

What PROs and CONs of these 2 options would come to your mind? 

[phil_bool_unifi]

You're right - the migration can be a pain.  No matter how you do it, the sys_ids of the records will change, meaning any related records will need to be reassigned.  That means cost plans, time cards, resource plans, etc. will need to be recreated or reassociated. 

Obviously, if you can avoid that then do, but if not, get them to close as many as possible first, then get them to manually recreate any that don't have any (or much) useful information in them in the new Teamspace, then migrate only those ones that are essential. 

Trying to run both at once runs a risk that people with access to both will update the old version instead of the new, or will create new ones in the old table.  Not an unmanageable risk, but likely to make the transition process longer and more complex.

(Sorry to sound like a bot, but feel free to mark my result as the right answer if it helps 🙂 )

[Kartik23]

Since you are implementing this from scratch, you can try looking at using flows.

Also take a look at this article and the attached document for recommendations and best practices for this use case: https://www.servicenow.com/community/spm-articles/enterprise-wide-deployment-recommendations-and-bes...

We are working on iteratively making this use case easier to handle and would love your feedback on the challenges faced today (and the article above).