Open a system that has been in production for a decade and you are not reading code so much as sediment. Each layer went in during some era when a particular idea was the obvious one, became load-bearing, and then stayed long after the idea stopped being fashionable.
You can usually date the layers.
The relational database with the stored procedures nobody will name: someone’s 2000s. The SOAP service everyone routes around: mid-2000s, pre-REST. The fleet of hand-assembled EC2 instances, half of them oversized, tagged by a person who has since left: the lift-and-shift years, around 2016. The Kubernetes cluster running four services that did not need it: peak container hype, circa 2018. The bare LLM call wired straight into a controller with no retry and no cost ceiling: 2023, the week after the demo worked.
None of these were mistakes at the time. Each was the reasonable choice for its era. The trouble is that nobody goes back and removes a layer. They only add. So a “modern” stack is a core sample: every trend of the last thirty years, preserved in the order it arrived, all of it still being paid for.
A migration is mostly the work of reading that core sample. Before you move anything you have to work out which era each piece came from, why it is there, and whether the reason still holds. Most of the real decisions get made here, not on cutover night. The cutover is only the part with a date on it.
Which is why it pays to know the eras cold: what each one was reacting to, what it left behind, and what its jargon means when a vendor says it back to you.
So I wrote the sequence down: a field guide to thirty years of modern tech, 1994 to now, in plain language. Ten eras, the people and companies behind each, and the terms you will meet in a vendor deck, with a note on what every era tends to leave running in production long after everyone moved on.
If you are staring at a stack you did not build, start there.