That must have been one heck of a rug pull if $270k was considered more cost-effective than getting someone to work on it sooner.
I suspect it's not so much that it was considered more cost-effective, and more that it wasn't considered at all. My impression was that nobody was even allocated to work on the transition until 8 months, because that's when we started getting emails from their devs, and the upgrade took them less than a week when they actually did it.
So did you return the correct data with the 426 Code?
No--the goal was to break the API so users noticed, with an easy fix. A lot of users weren't even checking the HTTP status codes, so it was necessary to not return the data to make sure the API calls broke.
We did roll this out in our test environment a month in advance, so that users using our test environment saw the break before it went to prod, but predictably, none of the users who were ignoring the warnings for the year before were using our test environment (or if they were, they didn't email us about it until our breaking change went to prod).
Clients weren't happy, but ultimately they did all upgrade. Our last-to-upgrade client even paid us to keep the API open for them past the date we set--they upgraded 9 months behind schedule, but paid us $270k, so not much to complain about there.