Tuesday 18 November 2014

How to migrate your developers to your new API

Here's a quick blog about a situation we ran into recently with one of our customers after they bought a large app:

You're one of these new fangled Cloud companies. You've got a service users buy, you've got an API third parties integrate with make the service more useful to your developers.

It seems inevitable that at some point in time, you'll create a new API and need to migrate users over - and perhaps eventually switch off the old one (especially if it had security/privacy concerns).

How do you get your developers to migrate over to the new API? Obvious right, you tell your developers, and they jump right onto days/weeks of extra work you just created for them...

Of course, some percentage of your developers don't migrate - maybe the email didn't get to the right person, maybe the person that did the setup left the company a long time ago, maybe it ended up in a spam folder, maybe the person was too busy at the time, and so on.

So what do you do? Well you told the developers, so it's their fault now - just go ahead and switch off the old API, right? How can it be your problem now?

What else can you do?

  1. Try harder to contact the developer. You collected all kinds of information when the developer signed up - it'd take a few minutes to look up their app on the App Store, find the support link and throw a email/ticket/post their way. (Okay, I don't really expect this would happen, it's labour intensive and I can imagine there's a large number of apps out there, but it might be a viable strategy for the top few percent of apps still hitting the old API.)
  2. Force the issue - temporarily disable the old API. If/when the developer gets in touch, explain the situation and re-enable the API for a stated grace period.
  3. Tell the users instead. Your users are the ones paying you, and by an automated cross-referencing of API keys, API version in use and user ids, you can see which users are using an app that's going to stop working. The users are a great asset here: some percentage of users will know the best way to get in touch with the app vendor. Maybe it's email, maybe it's a forum, maybe they leave 1 star reviews - but users are a resourceful bunch who will find the way.

Importantly, also make sure your support team is aware of this - there's nothing more frustrating to your users than support walking them through the usual "delete the app, try installing again and re-authenticating" when what's actually happened is your engineers have deliberately broken the API that the app uses.