How can you prepare ahead for Production Migration
This may be one of the most exciting parts of developing on any platform. Actually going Production live with the apps, processes, etc that you have worked on so hard for months or even years in some cases.
I recently had a big go-live and I was responsible for the most fun part of migration weekend — data migration and this included all businesses — Sales Cloud standard objects, CPQ, Support just from Salesforce platform but there was migration for other systems as well. So it did require a ton of coordination efforts as some other systems relied on Salesforce migration. So I will mostly focus on data migration in this post.
What can you do to prepare yourself in advance prior to go-live
A lot of planning and activities happen prior to the cutoff date. If you are lucky to work on a new org, you can explore some options that will make the weekend or go-live activities go a lot smoother. Let's talk about a few:
Align on a specific cut-off date for each systems
This may be a no-brainer but in a big project, every workstream may have its own timeline. Make sure you are aligned on all those dates to plan the migration activities for different objects of various workstreams. This means after X date no data will be coming into the old platform and if it does then you will need a plan for this post-go-live.
Migrate low-risk stable data prior to the cutover. Anything that can save time and be done prior, should be done beforehand.
If all the metadata(objects, fields, code, etc.) deployment are over 90% done 2 or 3 weeks in advance of go-live, then I suggest planning for data migration in advance of go-live, especially if you have a limited window for migration.
This will cut down the volume of records being migrated at once and make the weekend a lot smoother since you will be dealing with lesser volume.
This approach also has lesser chances of encountering surprising errors, as you have already run your processes once prior. This gives business users enough time to validate the data and make sure everything looks good.
If you follow this approach, you will have to be mindful of data changes happening in current systems and plan for updates. If you are using Upsert operation then you are already set. Use a flagging mechanism or filter to only migrate delta during the weekend or limited time.
This varies based on the client and the business model, but objects data that don't change so often are great candidates for pushing to Production in advance. Eg: User, Permission Set, Account, Contact, Closed Opportunities, Territory Assigment, Contract
Assess according to your own project whether this makes sense for your project to migrate certain objects prior to cutover or it adds more complexity. I have done it both ways. There is no one fits all solution.
Plan, Document, Share and Repeat
Work with the PMO or Project Leads in all workstreams, to make sure every step in each workstream is documented and shared. Owners are assigned to each step and a communication plan is set up. You should also ensure that you have decision-makers on each domain for any exceptions that may occur.
Trust me on this one. As you document all the small steps, it may feel overkill at times. But it is super important for many reasons. ..Emotional, Psychological, Audit and Governance, Ownership and Accountability.
Our brains tend to not be at their peak functioning capacity when you are in a time pressure or just go-live anxiety. So again, it's important to document everything even if you may feel you already know what needs to be done.
Have a Data Backup Plan in place before retiring old systems
This is a must-have if you plan to retire old systems, both from a validation, audit perspective. This adds an extra level of confidence with the migration knowing that data is not gone from Archives or lost even if there was some miss during the migration or you faced unexpected results. You are able to fix issues, compare with source data and make them available as requested. Particularly with data migration, more things come up as users start using the system.
Plan with Vendor/s as needed
Create a ticket with Salesforce and any vendors to notify them of the go-live plan so you can reach out if anything goes wrong. I had an issue where someone consumed all the API calls which wasted some time from migration. We had to call Salesforce and request an increase in API. This could have been super easy to resolve if there was a ticket with SF in advance.
You also may need to involve vendors for CTI, marketing packages to switch instances.
Perform Mock Loads
Get your project buy-in to plan for mock migrations at least 2–3 weeks in advance. This is even more important for enterprises and large projects. This will make you prepared for the majority of exceptions, time taken for each load, have business validate data.
It is crucial to document business valuation and approval after migrating each object into a mock environment. Once your org is live it becomes a lot harder to fix bigger data issues. You cant expect to have a system downtime or turn off automations during load.
What to do in the Cutover weekend or Go-live
If you documented all the steps and already have run the majority of processes prior whether in mock runs or pre-go-live loads, you can go down your list of objects or steps and perform each step as in mock loads.
If all goes well, then it will be an uneventful but great weekend but something is always bound to not go according to plan.
Eg: You are trying to load Cases but contacts aren't to be found. or loading contacts and Accounts not found, or some new validation rule was added, a picklist field was restricted, you get the idea.
You should have a point person from each business who has the authority to make decisions, it is super important to communicate and get approvals for any exceptions. Depending on the risk, you and the business may decide to resolve post-go-live. Document all the exceptions, that needs to be resolved immediately after all the steps are completed.
If it is something that is critical and cannot wait, then you may have to escalate to whoever is responsible for resolving the issue, assuming you already have done your homework. Is it a data issue, that you cant fix by using technology or is it a vendor issue or something else? Being very transparent and communicating is key. You don't want to catch anyone by surprise.
Last but not the least, Stay hydrated, nourished, stretch and give your brain and eyes some break.
I am guilty of this myself, where I get super hung up on an issue and don't move or blink until I have resolved it. But I have noticed over the years that when I just leave my desk for at least 5 min and come back, I am able to solve the problem much more quickly than staring at my screen for hours. So please take breaks!
I may have just scratched the surface, if you have questions on any particular issues or points I brought, please comment below. I also published an article on Data Migration Steps, if you are interested to check it out.
I have started a gofundme to help support 1 girl to pay a full year of school fee. I am passionate about supporting women to further their education and I will double any donation I can get. If you support my cause, I would truly appreciate that. If you can’t, that is okay. Please share with your circle if you like.