How do you move clients from an old and insecure integration API, to a new implementation?

Particularly when the clients do not want to?

Stage a break in. Or some other way to show the value of moving.

How much is their data worth?

Take a pitchfork. Ram it up in their arses.

In my opinion, the only way is to create a new API endpoint, deprecate the old one and set a fixed point of death.

All other attempts are futile.

hire a security audit company and red team them. A Webcam video and of the CEO eating boogers will maybe convince them. 🤷‍♂️

Loose support for the old api ASAP and publish an enddate, where the old api will be shut down and stick to it. If its possible create many points that will make it unavailable to the enddate, so if the managment decides to keep it up, the api will be at least partial unavailable.

The issue is I am just an employee. People will not want to risk upsetting clients so they won't listen to me about it. If I could just declare we are dropping support it wouldn't be a problem.

@stop

Why publish and end date? Be like some places that just kill it off and add it into the long list of release notes.

If it ain't working, it'll get fixed.

@C0D4 you cant shut down api so easily. You can get sued for not provided services too easily.

@stop if you just shut down a service, yes.

If you set a fixed point of time where the service won't be supported anymore, no.

You just need to offer an alternative.

This needs to be negotiated of course - but a client won't budge if you don't force them to do so.

Refactoring in the sense of trying to uncludge a broken API by _not_ providing a new API will have a higher cost than providing a new one. Bugs / maintenance spirale is real - fix one bug, create N additional ones. The loss of knowledge is an underrated - but very important - problem. Noone usually fully understands old stuff - every (new) dev working on the API needs a timeframe to get accustomed to the code base, which means that with every person involved the cost rises immensely. True for new services - of course, although preventable if you do your planning right. The third point of what I like to call the trinity of refactoring cost is depression. Your client gets pissed when things do not work, you team gets frustrated when it has to claw his way through the shit hole of code. Which means that development will take more time. Depression in the literal sense of "Noone wants this, everything slows down and is crippled".

Trinity of refactoring costs: Regressions, Lost Knowledge, Depression.

A client wants no changes.

But he will sue you if he looses money thanks to an security audit and realizing that you're the reason for the security audit (one example, thousands more possible).

Force him to do so. You can give a lot of good reasons - some of which should be partial lies, they're more convincing sadly than the truth - but in the end, make sure the client has no choice but to migrate.

Otherwise you're sitting on an endless money burning machine.

I think a lot depends on what changes the client will need to make in order to be able to use the new endpoint. If it’s simply just a URL change I think it’s perfectly reasonable to give them a new URL and then publish a decommission date for the old one. Happens all the time. If they need to re-work their calls (going from SOAP to REST, adding security tokens, etc.), then you can still take the same decommission date approach, but they just may need more time.

At my previous company they just sent an email that from tomorrow we have to use app for rsa authentication to read our internal emails. So everyone who haven't found and readed that mail from all the daily corporate email garbage and useless reports couldn't log in from next day 😂 It was like 99% of the workers. I was like congrats👌 miss ITIL certified IT manager.