Rebuilding software here means developing required functions from an existing system again. It may fit when the process still works but the application demonstrably limits changes or maintenance. Age alone isn’t a reason to rebuild. Compare the approach with targeted maintenance and an existing package; our guide to custom software helps with that broader decision.
What do you carry over when rebuilding software?
You carry over functions the business needs, rather than automatically reproducing every screen and old exception. The existing system provides evidence about the process. It isn’t a faultless specification.
A screen might require a field because a long-retired integration once needed it. Recreating that field preserves an old restriction. Meanwhile, an unobtrusive rounding rule might affect every invoice. You don’t want to lose it because nobody mentioned it during the first demonstration.
Have users carry out complete tasks. Observe the input, the outcome and what happens outside the system. A separate spreadsheet can reveal work the current application doesn’t support.
When should you choose maintenance, a rebuild or a package?
First establish why the application no longer meets your needs. A slow search might need a focused fix. If the supplier no longer supports a required function and nobody can change it, the problem may be wider.
| Approach | Reason to investigate | What to weigh up |
|---|---|---|
| Maintain existing software | Most of it fits and the problem can be isolated | Available knowledge, supported components and access |
| Rebuild functions | The process fits, but its implementation blocks necessary changes | Hidden rules, data transfer and temporary parallel operation |
| Adopt a package | An existing product supports your main tasks | Process changes, licensing, exports and missing functions |
| Redesign the process | Neither the working method nor the software fits | Decisions and staff support alongside development |
A package may cost less, but the subscription alone doesn’t establish that. Migration, configuration and changes to daily work count too. Equally, new custom software doesn’t become easier to maintain simply because it uses a newer framework.
An existing TopDevs case illustrates why the task matters. At Peters Bouwkundig Adviesbureau, work around older reporting software changed to tablet entry, photographs and standard text, followed by office review and document output. That case describes a changed working method, not a guarantee that recreating old screens is the right approach.
How do you make existing behaviour testable?
Collect representative jobs with anonymised inputs and expected outcomes. Include a cancellation, a correction and an incomplete record. Ask someone responsible for the process to decide which result is correct when the old application and current practice disagree.
Then separate what to retain, change and remove. For retained functions, record expected behaviour. For changed functions, deliberately describe the new result. Before removing something, check who still uses it and which other systems depend on it.
Start the technical trial with an uncertainty that could change the decision. Can you export the data? Is the new application allowed to use the required integration? Can it produce a representative report correctly? A successful trial answers that specific question, rather than proving the whole migration is feasible.
Can you switch without replacing everything at once?
Sometimes you can take over functions gradually while the rest keeps running. Microsoft’s Strangler Fig pattern describes an approach using an intermediary to route traffic to old or new functions. It requires the ability to intercept traffic and modify the existing application. Temporary infrastructure and dependencies add operational work; the approach doesn’t suit every system.
Moving a defined group of users first is another possibility. That only works if it’s clear where they make changes and how the rest of the organisation sees them. Two writable versions without ownership for each type of information make reconciliation harder.
Choose the transition according to how the work connects. You might replace a small standalone tool at one planned point. Shared order management needs agreements about outstanding orders, changes during transition and when the old route closes.
How do you check the data migration?
A successful import message doesn’t show that staff can use the data. Check counts, relationships and business outcomes. An invoice without its associated customer may have been stored successfully but still be unusable.
Use an agreed copy of the information for a trial migration. Record which fields are transformed and how unknown values are handled. Then have the team open familiar records, compare reports and find outstanding actions. Track differences until someone can explain or correct them.
Plan what happens to historical information as well. It might need to be searchable in the new application, or a separate archive with suitable access might suffice. Decide before the old licence ends, so you don’t discover a missing export after access has closed.
For the switch itself, agree when entry stops and which later changes must still move across. A fallback plan needs to account for newly entered information. Restarting the old server may not be enough if it doesn’t know about the new orders.
Can you recreate software owned by someone else?
Under EU software copyright law, the Court of Justice’s SAS Institute/WPL judgment distinguishes functionality from its expression. Functionality itself isn’t protected by that software copyright, while source code can be. The judgment doesn’t provide blanket permission to copy a product. Other protected elements and the circumstances of access still matter. This is the European context of this guide, not a universal rule for every jurisdiction.
Establish which rights and agreements apply to the actual project. Who owns the code, which licences apply, and what documentation or data do you want to reuse? Having paid for development doesn’t by itself describe your legal rights to reuse the work. Our guide to code ownership and supplier dependence helps prepare those questions.
Where rights are uncertain, get legal advice before reusing protected material. A functional description based on your own working process is also a better brief than asking someone to copy a competitor pixel for pixel.
What determines the cost of a rebuild?
The size of the new feature set is only part of the estimate. Investigating existing behaviour, filling documentation gaps, cleaning data and managing the transition take work too. Ask for those items to appear in the budget.
Compare scenarios over the same period of use. Include maintenance of the old system during development, possible duplicate licences and support after the switch. Our guide to software costs provides a framework for comparison; a fixed price range without this scope tells you little.
Identify remaining uncertainties and which trial could reduce each one. A fixed price needs agreements about what’s included, what counts as a change and who approves the results. It doesn’t make unknown dependencies disappear.
How do you prepare for maintenance and handover?
Request usable setup instructions, integration documentation and an overview of required accounts and licences. Have another maintainer use that information to set up a test environment. That tests whether handover amounts to more than a folder of source code.
Agree who applies updates, handles alerts and rehearses recovery. At TopDevs, the code is and remains yours. Ownership and the practical ability to continue development are separate matters; you need both if another supplier is to take over later.
How do you actually get started?
Describe the problem the existing software causes and choose a complete task for comparing possible approaches. Gather the expected outcome, access agreements and a data sample. That lets you define an initial investigation without commissioning the entire rebuild first.
Want to discuss what building custom applications means for your existing process? Book a call.
