The Ever-Present Pain of System Migrations

My primary experience with system migrations has always been managing them, but in recent months, I experienced them as an outside customer working with the front-line customer representatives of two separate companies in two very different industries. What I faced was the frustration that your own customers might encounter during a system change.

In the first case, I was ordering a new supply of natural gas for a residence, and the company couldn’t even take an order! The customer service person told me that the company was changing out their systems, and he couldn’t really tell me when they would be able to get an order processed.

I tried the next day, and the rep who was working with me got my order into the system, but then we couldn’t get a delivery scheduled, because the order system couldn’t communicate with the shipping and delivery systems. I finally had to go with another company.

In the second case, we had ordered a box of tile and had driven 60 miles to pick it up on a will call because we needed the tile right away. We were making the drive because the customer service rep at the plant told us that the tile had arrived and was ready for pick-up. We arrived at the plant and at the front of the service desk was a big sign, “Sorry for delays. We are in the process of implementing a new ERP system.”

“I’m sorry,” said the customer service rep. “I can’t give you the tile.”

“Why?” I asked, “Your office called and said we could pick it up.”

The rep didn’t know what to do. She tried to use the system and it froze. She called IT support, and support couldn’t figure out the problem right away. She asked another co-worker to help, and the co-worker couldn’t get the system to work, either.

By then, it had been about 40 minutes and all of us were tired and frustrated, especially since the box of tile was just sitting there, 30 feet away from us.

“I’m sorry. We aren’t supposed to release the tile without the paperwork, and we can’t get the release papers printed now,” said the rep.

I asked the rep to call a supervisor who might have the authority to manually authorize a materials release and hand-write the necessary paperwork, which could later be entered into the system when the system became operable.

“After all these years,” I wondered, “Why are system migrations so difficult?”

The reason usually comes down to system integration problems, but there also are subplots, such as angry and uncooperative vendors that might be losing an account; users on the front lines who don’t know what to do when systems fail; and poorly planned and executed migrations.

Collectively, these problems can render system migrations so painful that an IT leader or CIO could be led to wonder if it is even possible to effect a seamless and painless migration without a frustrating customer experience!

The answer is: Yes, I have seen it.

Best Practices for Ensuring Smooth Migrations

The companies I have known to be successful in planning and executing system migrations take these five approaches:

1. They never assume that system migrations are “business as usual.”

Nothing is “business as usual” when you are migrating to a new system, especially if it is as all-pervasive as ERP. Yet, so many businesses do nothing on the operations side to beef up with their best people on the front lines to handle glitches, effect workarounds and address customer complaints during a migration. Instead, they just staff as they normally would.

That is a mistake.

If you are in a severe system migration such as a changeout of an enterprise ERP system, supervisors and process experts should be on hand at all customer touch points. These touch points might be in-person, or on telephone, chat, etc.

Invariably, there will be hiccups in processes that can’t be detected or planned for ahead of time and that need to be resolved quickly. Meanwhile, persons with know-how and authority should keep the business processes running. Your customers will appreciate it.

2. Check with other companies.

In most case, your company will not be the first to perform a particular migration of a new commercial software package. Check around with other companies that use the product. What issues did they experience? Are they pleased with the new upgrade? What recommendations for implementation did they come away with?

The more you know about potential problems that you could encounter when migrating, the better prepared you will be for them.

3. Work with your vendors.

In some cases, it might be necessary to convert code to run with a new operating system or other system, especially if you are hosting software internally and moving all your systems onto a new software, OS/hardware platform. In a case like this, it is wise to secure the new vendor’s help in planning and executing the conversion. Also use any “conversion engines” that the new vendor might have that can automatically convert your code base to run on the new platform. Be equally sure that the vendor you are leaving might not be cooperative when it comes to helping you de-convert and leave. You can avoid vendor hostility by including a set of SLAs in your vendor agreements that address the possibility of de-conversion and enumerate the specific actions and responsibilities you would expect from your vendors in that circumstance.

4. Designate an IT “swat team”.

During the time of a crucial system migration, identify your very best people from every area of IT and assign them to a migration “swat team.” This team springs into action whenever a glitch or a disruption from the migration is detected so it can get resolved. A dedicated team of your very best people assures the fastest mean time to repair (MTTR), and limits disruption to the business. The leader of this team should be aggressive, earnest, communicative, decisive, and fast to act.

5. Establish rollbacks and set recovery points.

New database releases can be especially messy and disruptive when they are installed, because they touch so many applications.

One way to plan for them, after thoroughly reading all of the new release notes, is to ask questions and do everything you can to effect a smooth transition by treating those notes as a kind of DR exercise.

You can do this by establishing rollback and recovery points that can be exercised if something goes wrong, and you need to halt a migration and back out of it.

In this way, you can quickly restore the old release so your company can keep working, and user and customer frustration is minimized

What to Read Next:

IT Report Card: Customer-Facing Applications

Overcoming Top Cloud Migration Barriers: Strategies for Success

8 Secrets for Smoother Sailing During a Cloud Migration