I've included some notes from my own experience to help those (not necessarily parent poster) avoid similar failures.
- don't get locked in to single-vendor technology that might disappear on a moment's notice.
Realistically, evaluate if said technologies can survive company collapse or not. Languages / Technologies with heavy internal investment like C# are a lot more coupled to their companies than say PHP, Ruby, etc. That said, maybe the Mono/Apache/etc.. type groups out there could keep the lang alive if MS pulled the rug. Java could be better off if Oracle killed it to open up the ecosystem pieces they've kept ransom. HTML/Javascript are completely open (though standards keep things semi-coherent) but realistically 3-4 vendors control the narrative and if 2 decided to go in a different direction, you'll have a lot of chaos to keep things working.
- hide API's inside your own classes. That makes ripping them out and replacing them with something else so much easier.
Well, the general mantra of layering access to things certainly mitigates unnecessary coupling which is a good thing. This should be applied everywhere though, not just inner class scoping.
- stick to standards.
Yep, and invent some of your own if there's a lack of good standardization where there should be.
- invest in regular modernisation. Do it when reasonably can, not when you absolutely must.
A tricky proposition, but one that should certainly be striven for. Admittedly, saying lets drop all this stuff that produces more revenue to work on X which may eventually help us maximize revenue in the future is certainly not as clear cut, but in the ideal world, the code is always getting improved, polished, simplified, etc.. Writing (CS101 here) low coupled, high cohesion code will vastly simplify future improvements. Just make sure that you always consider 3rd party libraries / platform libraries / language quirks included into external dependencies that may evolve over time.
- refactor whatever stinks.
Whenever I try refacting crap (core piece of functionality), I write a TON of extra tests for before/after comparison because no matter how perfect your re-implementation, there will always be those bazaar corner cases that worked (possibly through fluke/magic) in the original spahgetti that violates the implied or explicit contracts in the future. Refactor for sure, but don't ripshod, or your eventual replacement will be refacting/fixing your POC for much the same reason you refactored.
- keep your own skills up to date. Apply as needed.
This is never bad advice, but just remember that just because you learn a new technique / technology, don't go running out to refactor everything to use it. Generally if it was popular 10-15 years ago, its probably stood the test of time and passed, while newer tech should be looked at carefully and evaluated for specific cases where appropriate.