Legacy .NET & Windows software
Repair first. Replace only when it's worth it.
If an older Windows application still runs an important part of your business, you have more options than “leave it alone” or “rewrite everything”. I maintain, repair and modernize .NET desktop software step by step, while the business keeps using it.
What I do
Get it building again
A reproducible build on a clean machine, the code in source control, dependencies identified and pinned.
Fix what hurts
Crashes, data errors, slow screens and broken integrations, in order of business impact.
Make changes safe
Tests that record how the risky parts behave today, before anything is changed.
Extend it
New features, reports or integrations, once the foundation is solid.
Modernize in steps
For example, .NET Framework to current .NET one project at a time, with the application usable throughout.
Repair, extend or replace? How I decide
| What I see | What I usually suggest |
|---|---|
| The core logic works and people are used to it | Repair and stabilize |
| You need new features and the foundation is solid | Extend what is there |
| It depends on technology that can no longer be run or secured safely | Migrate step by step |
| The business has changed beyond what the application can handle | Consider replacing it, after documenting what the old one really does |
Replacing is sometimes right. It's rarely the right first step.
How I work on legacy code
Build
Make the build reproducible and the code safe to work on.
Understand
Map the dependencies and document the critical paths.
Pin down
Add tests around current behavior where changes are planned.
Fix
The most painful problems first, in agreed steps.
Modernize
Upgrade gradually, and only where it pays off.
Questions about this
Our application isn't written in .NET. Can you help?
My focus is .NET, Windows desktop software and VBA. For anything else, describe the situation and I'll tell you honestly whether I can help.
We don't have the source code. Can you still help?
Possibly. It depends on the situation and on your rights to the software. Mention it in your first message, because it changes the approach.
Will you rewrite it in the latest framework?
Only if that's really the best option. Moving to current .NET usually happens gradually, and some applications are better off stabilized where they are for now.
Can we keep using the application while you work on it?
Yes, that's the normal way. Changes are made and tested separately, then rolled out in agreed steps.