Don’t Migrate – Integrate

Faced with a migration from your current software package? Lost a client to Oracle, SAP, Quckbooks? Many MV shops lose the war because they aren’t invited to the battles. And sometimes even the people who win wind up losing. There is a better way.

This isn’t intended to be a HowTo but to plant a seed and give you some ideas about how to approach a migration scenario. There are too many horror stories to count which involve millions of dollars and years of wasted effort, sometimes resulting in the decision to come back to MV. All of these efforts involved people who wanted to completely remove the existing system and replace it with something new.

When faced with a possible migration, whether you’re an end-user and your management is considering it, you’re a VAR and your client is leaving, or you are in management and contemplating a change – consider a transition from your existing system rather than a full migration:

• Use the existing system as a working model until a new system is completely prepared to replace it. The developers of the new system can easily see if they provide for required functionality because the MV system is still live.
• Do not go live on a new system until end-users certify that it does the job that’s required. This is sometimes difficult to ascertain until a new system is live but if a developer can test their code then an end-user should be able to run it in an alpha/beta state too. Some environments work fine in development but fall down when exposed to the real world, hundreds of users, etc. There’s not much anyone can do about this except to plan for stress testing a system – before it goes live! 
• Integrate, don’t migrate. In today’s world of SAAS and SOA it should be clear that the world does not trash old for new, they make use of the best resources for a particular job. You’ve all seen the products out there that have a picture describing where they fit – it’s a circle with them in the middle and connecting spokes going out to other products and technologies. Use the model and have new and existing rules, data, and user interfaces integrate one by one until each piece can be discretely removed.

There are residual benefits from the above approaches:

• Management gets to see the existing MV environment in a new light, as a capable component in an enterprise and not an isolated old relic to be discarded.
• Developers might themselves think that there’s no reason to replace specific components because the rules are already in place that do what they were just going to re-write in some other language. A sideways move to a new language or technology buys us nothing and the question to be answered at all points is, why are we replacing component X? By eliminating specific components from the re-development plan, and replacing it with a much less expensive integration strategy with a new environment, the project costs go down as well as the time to delivery.
• After a needs analysis where people serious consider which components they will integrate, they may conclude that ALL components need to be integrated – so why are they transitioning? Why not just put a new front-end on what they have and add the features that are missing? That doesn’t satisfy the "buy Oracle" clones but nothing will save a company from them.
• It doesn’t matter if you’re considering a complete re-write or canned packages like Oracle Financials or SAP. These companies and others have spent $Billions (ref for SAP) to allow their software to integrate with other software as part of their own divide and conquer strategy. If you’re going to transition anyway, make use of this and integration your UV inventory module with an SOP distribution module and Oracle for the accounting. This serves to bring down your costs and allows the company to transition in a controlled manner toward the ultimate goal.
• The longer you keep MV in-house the longer you stayed employed. It’s to your advantage to convince the powers-that-be that your tools of choice can still play a part in the company’s overall IT strategy.

It’s not enough to know that these things are possible. You need to pre-emptively ensure that decision makers are aware of the options so that they don’t even enter into discussions involving wholesale replacement. When new management comes in, schedule meetings that portray this technology in a modern light, lest the start having their own closed meetings to replace everything without knowing what they already have. Again, if the company gets some bonehead who is going to implement "change" at all costs, they you might as well start looking for a job anyway because you can’t compete with a mindset like that no matter what logic you toss at them.

I hope that helps some of you folks out there.