Change is good. And sometimes it is not just good, but necessary. Whether it is to reduce costs or gain additional functionality, you may find yourself considering migrating your operations from one platform or service to another. Or perhaps you find yourself so encumbered in technical debt that you have decided to scrap what you have done in the past and start over with a ‘greenfield’ implementation. Whatever the reason for the move, there are some common steps to take that will help ensure that your migration is a success.
If you are doing (or have done) a migration I am sure you have heard the requirement from the users “sure, as long as nothing changes from what I have today.” Not only is this requirement dangerous, but it often negates the entire reason for the migration in the first place. However, the users do have a point here. Migrating to another platform should not cause a major disruption in the daily operation of the business.
1. Take an Inventory!
First, take an inventory of what you have. This includes processes, integrations, data, code, configurations, and users. This is often the most painful part of a migration (especially if you are migrating from something that is not well documented).
After you know what you have, determine what you need. This can be slightly tricky. Determine first and foremost what must be kept for compliance or legal reasons, and if it must be maintained in the new platform/system or if simply having access to it is sufficient.
After you have determined what you must keep, look at what you want to keep. Just as if you were moving from one house to another, do you really need to keep that chipped teacup, or will you be fine (or even better off) without it? If you must keep it, would it be better off in storage?
Finally, the things that you do not need and don’t really want, what is the impact if you get rid of it? Keeping with our house analogy, you may find that there are things that you can sell or donate, and some things that are just better off recycled or destroyed.
2. Consider the Model.
As you are looking to move things into the new platform, take time to look at how the data was stored in the old system, and determine if it makes sense to keep it that way.
For example, let us assume that you are migrating a website to a new CMS. In the old site, some of the users maintained a few tables with the upcoming events on a single page. The new CMS has a scheduling component that interacts with a calendar app in real-time to display your information. You would not want to copy/paste the tables and consider the page migrated. Instead, you would want to take the data in the tables and import it into the calendar.
Or if you have a record for a customer that has 4 different possible phone number fields and 4 different email address fields. Instead, determine if the new system has something that can store Methods of Contact and move the data into the new structure related to the customer.
3. Plan Your Move.
How will you Move?
What is the best approach for your migration? What will be the lowest impact to your userbase, but have the greatest impact to the business?
Some of the common approaches that I have seen are:
Cap and Grow
The “cap and grow” approach is extremely common but is not one that I recommend. There are some clear benefits to this approach, but also some very significant risks.
By its design, all new users/records will conform to the new process. This allows you to reduce the costs and scope of maintenance on the old platform and enables you to migrate the remaining records and users in an orderly manner across a longer timeframe as resources are available.
However, this approach has some very real challenges as well. The first one is that users will have a bifurcated experience, especially if they need access to old and new data. This can cause confusion when you must determine which system a particular piece of data is in which in turn makes operations, support, reporting, and training more difficult. And even though the scope of maintenance is less than it was before, there will still be some additional maintenance costs for defects, training, documentation, and support.
A phased implementation allows you to migrate either portions of data/process at a time, or a specific subset of users in their entirety.
This lowers the burden of training/supporting a larger userbase for the migration and can keep potentially negative impacts isolated to a smaller group but increases the timeline of your rollout.
All or None
Arguably, the quickest approach to migrating your users is to go ‘all or none.’ This shortens the timeline for your go-live, but does not lend itself well to iterative or agile shops and increases the number of potential risks. Additionally, there may be doubled costs for development and testing for any new features prior to go-live if the new features are required before that date.
4. Planning the Migration
The first thing that I recommend migrating is the data model. Make sure that the underlying framework that your data will be stored in is ready.
After your models are in place, move your processes. This includes any code or declarative processes. One thing to keep in mind with this step is that automated notifications or callouts to external applications may be triggered when you load the data. If this is not desired, I still recommend making sure that this step is done second but turn off all the automation that you do not want to execute when the data is loaded.
Next, load any data (including files). Make sure that the data is migrated to the new models, not the old ones.
Finally, as part of your migration plan, hype it up! Provide regular updates to the users about the improvements coming in the new platform. Put together trainings, documentation, and demos and get it in front of the users early. Get their feedback, and address any concerns that arise early, especially from your power-users.
Practice. Practice. Practice.
There was a poster in my 6th grade band class that said, “practice only on the days you want to eat.” There is a proverb among martial artists attributed to Bruce Lee that says, “I fear not the man that has practiced 10,000 kicks once, but I fear the man that has practiced one kick 10,000 times.” And there is another old saying: “practice makes perfect.” These three all point to one common theme. If you want to do something right the first time when it truly matters, spend the time perfecting it before the moment comes.
Take the time to practice your migration before each part of the rollout. My recommendation is that you do at least 2 successful practice deployments before your rollout to try to catch any major issues.
5. Moving Day!
Whether you are doing the phased approach or the all-or-none, back up your data and files. This is a standard practice for deployments, and migrations are no exception.
Deploy your data and code. I recommend kicking all users that you are migrating out of the legacy platform at the beginning of your migration’s deployment window and locking them out until the deployment is complete.
Once you have finished the deployment and the users begin to login there will undoubtedly be questions and concerns. Set up a migration “war room” to support your users. Have developers and admins on hand to be able to address any critical issues that were not caught as part of the development/testing cycle.
Keep track of the numbers and types of issues. The key categories that I have found for migration-related issues are: User Training, Missing Data, and Defects. This will help you plan for the next phase of the migration and learn what you need to watch for in your next platform migration.
About the Author
Dan Curry serves as our Director of Global CRM Delivery and Architecture with over 14 years’ experience in creating specialized clients solutions in process automation, data-driven application design, and team dynamics. He holds multiple Salesforce and industry specific certifications. Outside of his professional life, Dan spends time with his family, is an active minister in his local church, and practices Gadi Kempojitsu and Krav Maga where he is both an instructor and mentor.
Director, Global CRM Delivery and Architecture
St. Louis, Mo