Rollout and Common Challenges
You’ve completed your discovery and installation, possibly even set up some demo personalization and marketing strategies to test locally. Next step is to unveil the magic to the world and start reaping the rewards of your labor. In this post we’ll talk about rollout strategy and common challenges to be on the lookout for.
Anytime new functionality is developed, there needs to be a launch plan. For brand new green field situations, it’s typically a simple as “turning it on” or “making it public.” Obviously, that’s an oversimplification of the steps involved in doing either, but often its much more streamlined than orchestrating an upgrade to something already existing. For this post we’ll be considering the approach taken for pushing CRM connect functionality into an already existing production environment. This approach can be repurposed for any site upgrade for that matter.
Determine your roll-out strategy:
There are several variations to rollout plans to accommodate factors such as aggressive timelines, lengthy review processes and complex hosting architecture. In my experience they all necessitate some sort of content freeze. The length of the content freeze is typically dictated by the content calendar and frequency of content entry. In more aggressive situations we often employ a content entry strategy where updates can be made to the live site, while documenting each addition or modification so they can be re-entered in the upgraded environment (usually just prior to launch or post launch).
The most ideal case will allow a strict content freeze during the following launch steps:
- Implement content freeze
- Create production backups of code and data. This will be preserved for disaster recovery as well as restored throughout development, QA and any pre-prod environment
- Create local development environment based on production backup sets.
- Typically, this environment points to an existing Salesforce sandbox account
- Perform installation and configuration locally, and push to a QA environment for testing
- QA environments also typically point to the Salesforce Sandbox data
- Perform initial testing and bug fixes
- Setup marketing rules and campaigns
- Final QA
- Push live – At a high level typically launching functionality follows a variation of these three approaches:
- Recommended: Employ continuous delivery plan to push code and serialized data live via automation
- Overwriting production with new backup sets based on QA or renaming and pointing DNS towards the former QA instance. This process should include pointing the integration to the production Salesforce instance
- Not recommended: Manually migrating directly into production via code and content packages
- All hands on deck QA and fixes
- Lift content freeze and celebrate
Disaster Recovery plan
With any rollout plan it is important to have a disaster recovery (DR) plan in place. The plan can be customized to support any content freeze strategy and may utilize one or many backup points along the launch process. Generally, automated production backups are already in place and these can be leveraged in your DR plan. We also recommend backing up non-prod environments prior to installing the Connect functionality since often these may include unapproved functionality not ready for production and may require re-merging once the connect module is launched.
For technology upgrades and implementations, marketing and IT teams must work closely together from the very beginning to ensure standards and compatibility can be maintained. Often however, these teams are separate shared resources with competing budgets and timelines. It is important to align the teams early and spell out the entire processes to ensure adequate responsiveness and engagement is maintained throughout the process.
Working with sandbox data
Saleforce makes it easy to create developer and sandbox accounts but mimicking the production data is often a hurdle. Due to security, privacy and licensing it may require manually seeding data. Manually seeding data can be quite involved depending on the amount and complexity of the Salesforce account.
The Sitecore CRM connector is a great feature and many organizations will be able to get substantial value utilizing this integration. Most implementations s will require custom facets and the supporting custom development involved to accommodate that work. Salesforce objects can be dependent on other relational objects which can lead to a more complex setup. Often, accommodating the implementation of custom facets is underestimated. There is substantial code and configuration involved to implement custom facets.
Once the connection is in place, it is typically utilized for marketing campaigns and personalization. If you’re using Google analytics as well, you may want to create additional goals, events and conversions to measure the customized user journeys. Triggers that are based on URL patterns may become less effective if the content on the page is changing dynamically. It is important to re-evaluate your tagging implementation.
Code and content management
Minimizing the functionality and content gap between all environments (Local, Dev, QA and Prod) is very beneficial. The more standardization in place to ensure necessary code and content can flow together upstream via continuous integration and continuous deployment, the less technical debt and risk of issues down the road. This can often involve a complex setup of third-party tools, scripts and server configuration. Thankfully XCentium has developers and Cloud Services teams with an arsenal of experience to shorten the timeline and risk.
For Sitecore modules and integrations it is important that the content assets deployed to all the databases (core, master, web etc.) are accounted for. This can be done via Unicorn serialization, Sitecore’s Developer Collection (TDS) product line or a package process performed manually or via automation script.
Utilizing the connector
Out of the box the Salesforce to Sitecore synchronization is performed manually through the Sitecore content tree by running preconfigured batch processes. In most cases customization is required to automate the process to a desired cadence. This requirement should be defined up front so an appropriate level of effort can be accounted for in the budget and timeline.