As I mentioned in my last post (Part 1 – Planning), we developed a plan to migrate a client from SalesForce to MS Dynamics CRM after a thorough but accelerated discovery plan. Our plan to move forward had four primary parts:
- Develop the new solution
- Migrate the pre-existing SalesForce data
- Train the users
- Go live
Now, I’d like to focus on how we developed the solution in Microsoft Dynamics CRM and migrated the data. Each step along the way was a small project in itself with its own tasks, budgets, and timelines, though they were executed concurrently. My company tracked these projects inside Dynamics CRM so that the team or management could see at a glance how the project was progressing and what needed to be done when.
Although development and building out a new solution is usually quite consuming, our team made the decision with the client to minimize development in order to hit our timeline and finish the project before the SalesForce renewal date. Finishing on time would save the client a significant amount of money. In fact, the savings funded a large piece of the migration project.
As our team was wrapping up the design phase, we installed Microsoft Dynamics CRM 2015 on premise. Depending on the client environment, installation can be straightforward or complex. When we need to work with existing systems, we prefer a new server (virtual or physical) in order to avoid complications. Although this client preferred a local installation, almost 80% of our clients prefer to use a hosted version of Dynamics CRM to minimize installation time, or the cost of licensing SQL, Windows, and other servers. Our team moved forward on the development and migration tracks at the same time.
Development track
The development track proceeded as usual. By using quick prototypes and getting early client approval for the system, we were able to minimize miscommunication and saved them time and resources. Though this was not a development heavy project, it was still critical to executing it on schedule.
Meanwhile, the migration moved forward by mapping SalesForce data to Dynamics CRM. While there were some frameworks available to convert data from one system to another, we wrote components specifically for SalesForce migrations to avoid costs and other technical obstacles we had encountered on other projects. Once the data mappings and transformations were complete, we started to move data into the system. First, we moved a select set of records for testing. This was a small enough amount of data to move quickly, but still covered all test scenarios we needed to cover each type of transaction in the new CRM system. Our ability to move subsets of the data was also key for two other reasons. First, it allowed us to move smaller amounts of data during shorter bursts of time so that users were not inconvenienced and downtimes were avoided. Second, we were able to migrate only the most recently added or changed records in SalesForce immediately before we went live on Dynamics CRM. Without this ability, we would have had to move the entire data set while the users were out of the system, most likely over the weekend, and any delay or hiccup would have jeopardized the timing of the entire project.
With the client’s help in verifying data, testing new functionality, and reports, we were able to migrate all the data they needed in order to avoid their SalesForce renewal and move forward on their new solution. Next week I’ll discuss how we wrapped the project up with training designed to foster user adoption in addition to “as needed” live support on the first few days of the team’s use of the new system. View our Salesforce migration – Part 3 post