Taking over someone else's business application is not a coding problem to begin with. It is a comprehension problem. The code is the only complete specification that exists, most of the people who wrote it have moved on, and the parts everyone warns you about are rarely the parts that actually bite.
So we do not touch anything for the first two weeks. We read. Here is the order we read in, and why.
1. The deployment path, first
Not the architecture. The deployment path.
Before anything else, we want to know how a change gets from a developer's machine into production, who can perform it, how long it takes, and what happens when it goes wrong. If nobody can answer that confidently, that is the first thing to fix — because every improvement after this point depends on being able to ship safely.
The questions worth asking early:
- Is there a build that runs anywhere other than one particular machine?
- Can you roll back, and has anyone actually done it?
- Are the environments genuinely alike, or is production quietly special?
- What is the longest the application has gone without a deployment, and why?
A team that is frightened of deploying will avoid deploying, which means changes get batched, which means each release is riskier, which reinforces the fear. Breaking that loop early pays for itself across the whole engagement.
2. The database, before the C#
In most business applications, the database is the real system and the application is a user interface bolted to it. That is especially true of anything that has been running for a decade.
We look at:
- Table count and the shape of the core entities. Several hundred tables is normal and not, by itself, a problem.
- Stored procedure size. A procedure running to several thousand lines usually means business rules live there and nowhere else.
- Where the money is calculated. Financial logic — billing, commissions, invoicing — tends to be the least documented and the most dangerous to touch.
- Indexes and the queries that ignore them.
- Dead tables. Every long-lived schema has tables nobody has written to in years. Knowing which ones are dead makes everything afterwards easier.
3. The seams
We are looking for the boundaries that already exist, because those are where change is cheap. A service class that everything routes through, a scheduled job that owns a whole workflow, an area of the application nothing else references.
Good seams are where the first REST API can go without disturbing the screens. Their absence tells you something too: if every screen talks straight to the database, the first piece of work is creating a seam, not using one.
4. What people actually complain about
This one cannot be found in the code.
We ask the people who use the application every day what annoys them. The answers are almost never what management thinks they are. Frequently it is one screen that takes 40 seconds to load, a report that has to be exported and fixed by hand every month, or a workflow that requires a phone call because the software cannot express it.
Those complaints are gold. They are specific, they are verifiable, and fixing one of them early buys the credibility you need to do the larger work.
5. The things nobody mentions
Finally, the quiet risks:
- Hard-coded credentials in source control.
- A scheduled task on someone's desktop machine that nobody documented.
- An integration with a third party whose API version is deprecated.
- A certificate with an expiry date nobody is tracking.
- A single developer who is the only person who understands one module.
These rarely appear on a project brief and are usually more urgent than whatever was on it.
What comes out of it
At the end, we can explain how the system works — including the rules nobody wrote down — and we produce a staged plan: what to fix first, what can wait, what is expensive, and what is genuinely risky. We share it whether or not the client continues with us. It is their system, and they should have that document regardless.
The thing we almost never recommend at the end of two weeks is a rewrite. Not out of principle, but because after reading the thing properly you can usually see a cheaper path — and you have finally understood how much business knowledge is encoded in the software that a rewrite would have to rediscover.