One of the most frequent questions we hear in our CRM practice is “how can I migrate from SalesForce to Microsoft Dynamics CRM?” Many SalesForce customers we talk with have a variety of concerns that drive them to consider migrating off the platform, including user cost, data storage cost, and technical concerns.
- User Cost – It’s not uncommon for a company to plan on using one SalesForce product, only to find out later they actually need to use a different SalesForce product and spend more… sometimes much more. This can be due to undiscovered requirements during the sales process, additional “nice to have” features, or even changes in a client’s business processes. Costs can also drastically increase in later years of a contract if you negotiated a substantial discount in the beginning. On top of all this, SalesForce is priced at a premium, and some companies don’t consider it a good value.
- Storage – Despite the best of intentions, companies sometimes underestimate the amount of data they’ll need to support sales, marketing, and operations. This isn’t necessarily a bad thing, as it usually means you have good adoption. After all, users entering data is what you want in a successful implementation. Nevertheless, unexpectedly exceeding your data limits can add a significant level of unforeseen cost.
- Technical Concerns – Some companies found one or all of these concerning: 1) SalesForce wasn’t as easy to integrate into existing production systems as expected, 2) it didn’t offer any flexibility in deployment options, 3) who ultimately owned and/or controlled sales data.
When a company determines it would like to look at other options, it starts by searching for competing solutions. We’ve had the opportunity to work with companies who recently went through this process, and I’d like to discuss one project in particular in which we faced a tight timeframe from a client in a hurry to migrate.
In this blog, I’ll outline Step 1 – Planning. Like any good deployment, a SalesForce migration starts with a good plan, and the most crucial element in these plans is usually the date your contract expires. Once we identify the prospective go live date, we prefer to add a few weeks of cushion and then schedule backward from there including time for discovery, building a new solution, migrating and testing. Since few projects go exactly according to plan, it is best to build in time for unexpected events though some timeframes are tighter than others. On this project, though, the client started their search a bit later than most and only had two months to go before their SalesForce contract expired. If we couldn’t migrate them in time, the client would have faced a costly renewal or the prospect of running the business with no CRM. Neither of those options was attractive, to say the least.
Since we had a firm deadline, it was time to examine requirements. What was working today and what was not? What did the client want in their new system that they didn’t have now? How important was it? Ultimately, this company decided to maintain their current business processes, reports, and data structures to keep the number of variables to a minimum. This made NexTec’s challenge more surmountable by limiting this part of the project to documenting their existing system and how users engaged with it. Although we did identify things the client wanted to change in their system, we decided together to move those items to a later phase when deadlines were not so pressing. NexTec then created a detailed project plan outlining actions, responsibilities, and deadlines for the activities on the project. We knew there was very little slack in the schedule for hiccups along the way, but we had already migrated several SalesForce customers to Dynamics and already knew what to expect.
Once we knew what to do and when to do it, we had to execute the plan and keep a sharp watch over it. I’ll discuss some of those tasks, and a few challenges in my next blog. View the Salesforce Migration Part 2 post