You have been handed a PLM system. The person who built it has left, the documentation is a folder of screenshots from 2021 and users have opinions. Somewhere in there is a configuration that mostly works, holding several years of product history.
The failure mode in this situation is not inaction. It is confident action — changing something that looks obviously wrong and discovering three weeks later that it was load-bearing. Almost every odd configuration choice you will find was a rational response to a constraint that may or may not still exist. Your first job is to find out which.
Days 1–30: find out what is actually true
Read the lifecycle maps before anything else. For each item type that matters — part, document, change, CAD — write down the states, who can promote between them and what fires on each transition. This single artefact explains most of the system's behaviour, and in most inherited systems it does not exist in written form anywhere.
Inventory the server-side code. List every method, what triggers it and whether it runs on create, update or promote. You are looking for two things: code that fires on events you did not expect, and code nobody can explain. Nothing else you do this quarter is safe until you know what runs automatically.
Find the integrations and test them in both directions. ERP, CAD, anything else. Confirm what triggers each one, what happens when it fails and whether anyone is notified when it does. Silent integration failure is the most common serious defect in inherited systems, because it produces no error anyone sees — just data that is quietly a week out of date.
Establish who the real users are. Not the org chart. Pull actual login and transaction counts for the last quarter. You will usually find a small group doing most of the work and a large group who were trained once and never came back. Both facts are important, and the second is more so.
Do not change anything this month. Write things down instead. The temptation to fix the obviously-broken thing in week two is exactly the trap.
Days 31–60: find out what hurts
Now talk to people, having earned the right to ask specific questions.
Sit with the heavy users and watch them work. Do not ask what is wrong — ask them to show you a real task, and watch where they hesitate, where they open a second window, where they say "you just have to know that". Every one of those is a defect, and the users will not have reported any of them, because people stop reporting friction they have adapted to.
Ask for the spreadsheets. Somebody is keeping data outside the system. Whatever is in that spreadsheet is a precise specification of what the system fails to do. It is the most valuable requirements document in the building and it is free.
Ask the leavers, if you can. Anyone who stopped using the system will tell you why in one sentence, and it is usually the sentence you most need.
Now classify what you have found. Three buckets: things that are wrong (actually broken), things that are annoying (work, but cost time) and things that are merely unfamiliar (fine, just not how you would have done it). The third bucket is the biggest and it goes in a drawer. Rebuilding a working system in your own idiom is the most expensive way to add no value.
Days 61–90: fix one thing properly
Pick a single problem from the "wrong" bucket. Preferably one that is visible, bounded and belongs to a group who will say so publicly when it improves.
Fix it end to end: the configuration, the documentation, the affected users told directly. Then measure it — even crudely — so the improvement is a fact rather than a claim.
One properly finished fix in the first quarter buys you more credibility than five half-finished improvements, and credibility is what you will spend later when you need to argue for something harder.
The three traps
Rebuilding what you did not design. The strongest urge in this job and the one to resist longest. Unfamiliar is not the same as wrong.
Upgrading before you understand it. An upgrade is a bad way to learn a system, because it changes the ground while you are still mapping it. Unless you are on an unsupported version with a security exposure, defer it.
Believing the documentation. Where it disagrees with the system, the system is right. Treat the docs as a record of intentions, not of behaviour — and update them as you go, because you are currently the only person who knows both.
What to write down for whoever comes after you
You are living through the consequence of a bad handover. Do not pass one on. Keep a single running file with: the lifecycle map for each item type, every server method and what fires it, every integration with its failure behaviour, every non-obvious configuration choice with the reason and the running list of known problems you chose not to fix and why.
That last one matters most, and it is the part everyone omits. A future administrator can rediscover what the system does by reading it. They cannot rediscover why you decided something was not worth fixing — and without that, they will spend their first quarter relearning it, exactly as you just did.
Working paper. If you have inherited a system and want a second pair of eyes on what you have found, get in touch.