Migration Anxiety… real or imagined?

There is a reason so many companies are using software and servers that are 1, 2 or 10 versions behind the current ones. Fear! Fear of cost, Fear of downtime, Fear of data loss, Fear of losing your job in the wake of an upgrade catastrophe. Are these fears legitimate? Absolutely, as all of the above can easily happen. Do you have a choice? Can you keep using what you have indefinitely? Probably not. How about some Anxiety Therapy? To overcome any fear you need to face it. But let’s not face it with yours. Let’s use an example of another organization… stings less.

A few years ago I was a Volunteer Counselor with SCORE. SCORE is a national  organization that is funded by Congress to help small businesses for free… a noble and excellent organization.

Now SCORE was founded in 1964 and I think some of their data systems were just as old. SCORE provided their chapters with a database system for logging their client meetings and chapter administration, but over time, many of the over 400 chapters had developed adjunct systems of their own. Most had a website of their own and many had other calendaring and contact systems they had implemented. SCORE had evolved into what seemed to be 400 separate organizations. So the higher-ups in Washington lobbied Congress and received a grant to develop an entirely new “modern” system and move all the chapters onto it. I was invited to Washington to head the Testing group on the team charged with this undertaking. Armed with a boatload of cash, SCORE settled on Drupal for their CMS and Salesforce for their backend system.

SCORE had a legacy database of millions of records in an antiquated system, one that the more than 12,000 volunteers hated, but were at least knowledgeable of. We were to recreate this system in Salesforce. We were also developing an organization-wide website in Drupal where each of the chapters would eventually do away with their own websites and instead have a subsection within the Drupal CMS for their chapter sites. Just to add a little complexity, let’s add the fact that SCORE originally stood for “Service Corps Of Retired Executives”… so the average SCORE volunteer was not particularly tech-savvy.

In the original plan, we were going to bring over a few chapters at a time, and over a period of many months we would have everybody on the new system. The problem, was with the migration from the old database system to the new Salesforce system. Since they were going to migrate in phases, they could not turn off the old system and keep fully audit-able records (a requirement of Congress). Users would have to enter their data in both systems until the transition was complete. Needless to say, this did not go over well with the volunteers, in fact it sparked just short of a complete revolt. So a decision came down from somewhere that the only solution was to move everybody at once, and on a certain day everything would be switched over.

Can you imagine the Chaos? Well I could, and I decided my “volunteering” was going to become a full-time job so I left the project to watch the Titanic from the shore. The day came, the switch was flipped, and the predictable turmoil ensued. Within a week SCORE had been forced to switch back to the old system. Millions of dollars had been spent and they were right back were they started! I have not kept up with where the project is today, so I cannot say if they ever figured it out, but in any event some clear lessons should have been learned.

So what are the lessons? Granted, this was an enormous undertaking… no doubt far more complex than your switching one CRM for another, but the biggest lesson still applies to you. Where the SCORE project failed was with the concept of:

Old System > Migrate > New System

What else could they have done? How about:

Old System > Integrate > New System > Phase out old system

Where SCORE’s logic was flawed was with the idea of just “flipping a switch” from an old system to a new one. Instead, what they should have done was to integrate their Old and New systems. Synchronize the data sources and let them run in tandem. There would be no loss of data as both systems would actually have all the data. This way chapters could transition over time, and eventually, after everybody was comfortable using the new system, they could have just phased the old one out.

Integration is the key and you will be hearing a lot more about that concept from me and others is this space because “Integration is the antidote for Migration Anxiety”.