Go to portal
Shadow IT has become a big hidden cost for organizations, especially since SaaS platforms came into being. In the Salesforce space, a pattern which we see repeating itself time and time again is that a large enterprise acquires the platform under the direct ownership of an individual business unit. Maybe even different departments set up their own custom-built orgs, which are typically directly customized by the business users. But the moment comes when upper management realizes that this is an ineffective and inefficient way of leveraging the power of Salesforce, and IT is given responsibility to integrate the different orgs and to apply common standards across them.
Emerge from Shadow IT
Migrating an org under the responsibility of the IT department requires a proper and structured hand-over process. Below are some of the main points to consider:
– Understand the main stakeholders – platform owner, business relevant people, technical support teams, developers and admins, end users, …
– Understanding of the functionality being customized in the org
– Licensing and commercial agreements
– Service providers being used, if any. Current contracts, past contracts.
– Maturity of the tech teams with regards to their experience in software development
– Release management activities (if any!)
– Review of the issues and tickets opened by the end users (probably these are going to be emails to the admins!)
– Project documentation (if you are lucky)
The due diligence
And now, the fun part of the journey can begin.
Once we know the theory about the orgs, we need to understand the reality of each of them. This means getting a thorough understanding of the below points. This can be achieved through a tedious and error-prone manual process, or we can automate and drastically simplify gathering the information for most of them by using a tool like Quality Clouds:
– Level of customization and configuration of the org
– Quality of the customization – Technical debt, number of issues, non-adherence to best practices
– Current usage of the org
– Is the org reaching its limits? Or maybe it is being under-utilized?
– Number of different developers that worked in the org
– When it was first configured
– Data: architecture and its quality – which is the source of truth?. (With data inspection tools such as field trip running to ensure that new added fields are in fact being used)
– GDPR and data privacy review
– List of all the admin and developers profiles for each org
– This is the stage at which a comprehensive regression test pack should be created (since it is quite unlikely that one exists already). This should be based on the functionality you discovered being implemented in the different orgs (yes, Quality Clouds will help here as well)
Keeping the lights on and avoiding a return to Shadow IT
Once we know all the above, we can start designing the best approach to consolidate the different instances. There are a few main strategies which we can choose to tackle Shadow IT.
A first option would be to just connect the orgs, ensuring that the relevant data flows across them as necessary. One disadvantage of this approach is that users need to be directed to the relevant org depending on the function which they need to perform.
Another approach is to migrate all the code and data to a central org. Naturally this will depend on the different Salesforce clouds or solutions being used in each org.
Whichever approach is chosen, the lights need to be kept on while the consolidation process is ongoing. The first recommendation is to take control of all developments and service providers. It’s also a good idea to enforce a code freeze period where only critical changes would be allowed.
Now, let’s merge and rightsize!
At this stage, the migration project will start. Migrate code and data in a sandbox or test environment and ensure that you run your regression tests. User Acceptance Testing is a critical part of this step. Often it is best to involve the users as early in the process as possible, rather than waiting for a big bang approach to testing after the consolidation is complete.
Once all is ready from a technical point of view, clear communication to the end users with regard to the changes they can expect is also critical for the success of the migration project.
Also, ensure that you a clear process is defined with regards to change management on the new platform. This should cover the process to define and prioritize the implementation of new functionalities, ensuring that the standards and quality gates defined by IT are followed, and including the maintenance and operations aspects. Otherwise, you risk a return to the realm of Shadow IT.
Finally, do not forget to decommission the instances you don’t need anymore and delete any sensitive content which they could hold.
Keep on taking the pulse of your orgs
Even once everything is running smoothly in the new platform, all is not done. A continuous monitoring and improvement model needs to be defined, since without it Orgs can get messy quite easily. A regular analysis of your pre-production environment and a daily one in your productive orgs will save you lots of headaches and money in the medium and long term.
