Plan Exit/Migration Strategies for your 3rd Party Integrations

In this highly interconnected world our products or services rarely operate in complete isolation. We rely on 3rd or external parties for services or logic that we’d rather no do ourselves, well at least most of us. When I first started in software development I always did it myself. “My solution will be better, it will be exactly what I need, my implementation will be more flexible, etc, etc, etc” those thoughts would always come up when I needed something outside the domain of what project I was working on.

Now days, I look for external products or 3rd party solutions that meet the 80% rule. “Will this product/solution meet 80% of my core needs?” If it does, I jump on it. I’d rather spend my time taking the product or service the last 20% (which probably has more value to my business) then coding the entire thing. You might be able to build a better wheel, but should you try? When your trying to build a while new vehicle should you spend your finite amount of time and energy on it.

Because of this my products usually have a good number of external integrations, but that brings risk along with it. What if the service shuts down? The API changes? They pivot into something completely different. What happens when the stop supporting the product or code base? So what do you do? As my friend Dale would say, “That’s an uptown problem” and for the most part I agree with him. You can’t see into the future so how can you really mitigate that risk without waiting a whole lot of time.

Although it is a “Uptown problem” it can very quickly and without notice become a “it’s in your house” problem. As it did for us at Resgrid which is a SaaS deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

So what should you do before hand? Here is our list of data you should collect when you intergrade a 3rd party solution into your product.

• Research alternative services/products and compare contrast it with your current solution. This will help you identify other potential external 3rd party migrations. Keep the list short, at max the top 3 other solutions, but elect the ‘Plan B’ option and have some additional information on it compared to the others.
• Spend an hour and determine if it could be done “in house” and how much time and effort would be required. Determine the high level work that would need to be done and how it may be composed.
• Is it possible for your product to work without the service? If so can you turn the feature off easily to hide the issue. Do some brainstorming and have a plan of action if this is the case.

Share your findings with the team to build up some institutional knowledge then store it in a wiki or central documentation location. When you may need this knowledge it could be without notice. For us at Resgrid, we discovered an issue sending SMS gateway email’s to AT&T customers during our standard Friday deployment. Customers not being able to receive text messages from Resgrid is a big deal so we investigated and decided that we needed to implement Twilio. A day latter we had a working solution in production and our AT&T customers hopefully didn’t notice any issues. Because we had been investigating Twilio already we had some institutional knowledge built up and could implement it quickly.

If we didn’t have the knowledge built up, we could have wasted a lot of time researching alternatives, putting hacks in place and possibility making it worse. Just because something may be an “Uptown problem” doesn’t mean you shouldn’t invest some time now to help easy pain in the future.