Our Company Was Acquired Then Split Into Two Companies - We Share Workfront

[CarrieDowning]

Wonder if any of you ever get the recommendation from Workfront to always hire an external consultant when you have a bit of an overhaul to do within your WF instance? I'm on round 2 of needing to make some pretty significant changes within our instance and I'm being told to hire a consultant again. I come here for small questions/help/suggestions but wonder if my new situation is too large of an ask here and the consultant is just the way to go? I guess I struggle with what's appropriate to ask within the community and what's over-stepping my boundaries with your "free" help.

My company was acquired and then split into 2 companies. We are considered sister companies and are both owned by the same private equity firm.
During our contract renewal, we decided to keep the single instance of WF and play nice in the same sandbox, so we're contracted together. However, we are not split within the instance. We're tripping over each other’s forms, templates, queues, reports... list goes on. We've tried to take some initial steps in copying things and identifying them with their company initials and ours, so if we need to make changes to a custom form, we change ours, so it won't mess theirs up. But this isn't enough.

How can we separate within the same platform and not bump into each other. I've explored Companies but it looks like there can only be 1 primary and really, we both primary. Right now, all their users and all our users share the same Home Group (the original home group of the non-existent company). I know we need to create new Home Groups and just reassign the people accordingly, but I know that in my simple mind, that it can't be that easy. Doing what I "think" needs to be done, could very well break something in the system and I don't want to do that. We've got to get this figured out and I thought I would try here to see if anyone else has experienced this and how you handled it. Our old company name is still our URL as well - a company name that doesn't exist and it's a bit of a confusing thing for some. Why would I be logging into a system for a company name that no longer exists? I've also asked for this to be changed or perhaps we could obtain a vanity URL to point to the URL of our instance. Not sure if anyone has had this come up as well. As always, thanks for your consideration - just trying to see if I can avoid another chunk of change being spent for a consultant. I feel like between me and the other company Admin, the 2 of us could do the work, we just need someone much smarter than us to guide us along with dos and don’ts, so our WF instance doesn't implode. Thanks again. Carrie

[Doug_Den_Hoed__AtAppStore]

Hi @CarrieDowning,

Speaking on behalf of one of those external consultant whom Workfront recommends in such situations...

As a general rule, we (as does Adobe Workfront) encourage users to stay "under the same roof" within one instance, especially where at least some work is being (or might eventually be) shared between the groups. If however, that will not be the case for you, even with the many improvements Workfront has made to help segregate data (e.g. Companies, Groups, Group Admins, etc.), as you've noticed, there are still many areas that remain common and can cause friction; and even some global settings that can only be set one way or the other.

Over the past several years, we've helped many Workfront clients in your situation using our Workfront Merge (or Split) service, and your hesitation is well founded: it is among our most complex, expensive, and time consuming offerings. Now, if your main goal is to replicate "plumbing" (e.g. Custom Forms, Reports, Dashboards, Users, etc.) but can live without (and/or would consider archiving, via our Workfront Snapshot solution) the in-flight data (e.g. Projects, Tasks, Issues, etc.), we also offer a Workfront Config Merge service which can automatically transfer the former in a single day, saving weeks (or months, in some cases) of mundane effort to manually recreate such items.

That said, I suspect others can share tips on:

• how they manage to co-exist within the same domain
• what they've not been able to keep separate within the same domain
• how their Split went, for those who've been through it, and 
• if so, whether it was worth it in the end

Given that, I suggest you watch this space for other stories, but would also be happy to chat further sometime if you'd like to email me at doug.denhoed@atappstore.com

Regards,

Doug

[skyehansen]

we changed our workfront URL a couple of years ago and it was a pain in the rear from three different areas.

1) User: We informed users but of course the ones that don't log in regularly and ignore their emails don't get the message. There's also old training materials or old links people share that leads to this confusion. I think we may have also had to update our SSO creds.

2) Inside Workfront: We had a bunch of calculated fields and URL fields in our instance that pointed to the old domain, also external links in dashboards pointed there. This all had to be changed.

3) Fusion: We had to discover every module that might be independently calling our old domain and edit it to call the new domain. However, finally, Fusion itself stopped working on the day, and we were unable to authenticate into the new domain, leading to a bunch of weekend work for some very patient engineers over on workfront's tech support team.

Spending a few initial hours by hiring a consultant to walk you through whether to merge or split is also a valuable time saver -- me personally I would think that the risk lies more in splitting than merging. (when you say "split", my brain asks: what happens if a user changes companies? what happens if in the future, there's a body of work identified that needs workers from both companies? what happens if a project is started in one company by mistake and needs to be moved to the other company?) -- but a good consultant can really help you explore all your options.

[Madalyn_Destafney]

I definitely recommend one instance and utilizing Companies AND Groups within those companies. Object sharing/perms/access levels will be key here so you're not experiencing the stepping on each others' toes you're describing. I recommend having Group admins and/or some overall sys admin(s) that oversee whole instance and work closely with Group admins (not sure of your org size with both companies combined?).