Congratulations, It's Yours Now: Inheriting Systems Nobody Wrote Down
When the people who built a system move on, the system doesn't. Neither do its quirks. Here's what I learned taking over SSL, redirects, a store locator, and a product importer someone spent four years building.
The handoff that wasn't
Nobody ever sits you down and says, "Today you will become the owner of four systems you didn't build." It just happens. A couple of engineers move on, and one morning you realize the SSL certificates are yours. And the redirects. And the Where-to-Buy store locator. And the product importer that syncs Salsify into Sitecore, which somebody spent about four years building and tuning.
Some of it came with notes. Some of it came with the code and good luck.
This isn't a complaint. It's how a lot of engineers learn. But nobody teaches it, so here's what worked for me.
Rule 1: Don't touch it yet
The urge, when you inherit something, is to fix it. It's ugly, it's confusing, and you can see three things you'd do differently.
Don't. Not yet. Your first job is to understand what it actually does, including the weird parts. Especially the weird parts. That strange-looking line might be the only thing standing between you and a very bad Tuesday.
I start read-only whenever I can. Look, log, compare. Change nothing until I can explain what I'm about to change and what it'll affect.
Rule 2: Follow the fingerprints
Systems leave clues about what they've been up to. You just have to know where to look.
With the importer, one of my favorite clues was who last touched a page. When a product page shows it was last updated by sitecore\anonymous, no human did that. That's a script. In my world, sitecore\anonymous is the "nobody" in "nobody touched it."
Following those fingerprints is how I figured out the old importer was making changes it shouldn't have. The edit history pointed straight at a script, not a person.
Page looks wrong
↓
Who touched it last?
↓
sitecore\anonymous → a script did this
↓
Which script, and why?Rule 3: Keep the old version
When I did replace the importer, I didn't just swap it out and hope. Each new version went to QA first. The brand team approved the results before anything touched production. And every time I replaced the production script, I kept the previous version as a backup.
That backup is the cheapest insurance you'll ever buy. It costs nothing, and the day you need it, it's worth everything.
The new version is in a good place now. It used to need constant tweaking whenever a brand was added or something failed. Now adding a brand is mostly configuration.
Rule 4: Write it down for the next person
Every time I figure out something about an inherited system, it goes in my notes repo. The scripts, what they do, what broke, and why.
The next person who inherits this stuff might be someone new. It might also be me in six months, having completely forgotten why I did any of it. Either way, they deserve better than code and good luck.
The part nobody tells you
Inheriting systems can make you feel like a bit of a fraud. You didn't build it. You're just the person keeping it alive.
But keeping something alive, understanding it, and leaving it better than you found it is engineering. It might be the most real kind. Anyone can build something new. Making somebody else's four-year-old code behave in production is a skill.