From the team behind aidrop.it — one workspace to build, host, and keep changing your code.
When comparing legacy app rewrite services, ask each provider to explain what must be replaced, which existing behaviour must survive, and how users will move to the replacement. A proposal should connect the expense to a specific constraint: unsupported dependencies, changes the team cannot deliver, or operating costs the business can no longer accept.
The first useful deliverable is an assessment with evidence from the running application. It should leave you able to choose between repairing the current system, replacing one part, and rewriting the whole product. Use the brief below to ask several providers for comparable answers before commissioning implementation.
What should a rewrite service include?
A rewrite engagement should cover discovery, behaviour verification, data migration, delivery, and operational handover. Ask who owns each activity and what proves it is complete. Rebuilding the visible screens is only part of the work; scheduled jobs, permissions, integrations, and exception handling often determine whether the replacement can take over.
Request a list of critical user journeys and examples of their current outputs. An invoice export, for example, may depend on rounding rules that nobody put into a requirements document. Turn those examples into acceptance checks before asking a new implementation to reproduce the result. Taking over an existing app starts with this kind of evidence.
How do you know a full rewrite is justified?
Ask the provider to compare a full rewrite with the smallest change that removes the stated problem. A slow report may need a query fix; an unsupported runtime may require an upgrade; an inaccessible deployment process may need reconstruction. The recommendation should name what each option fixes, what remains, and what the team must operate afterward.
For a system that can change in stages, Martin Fowler's Strangler Fig approach describes gradually replacing functionality while the existing application continues to serve other paths. This requires a workable boundary and a plan for shared data. It is an option to evaluate, not a guarantee that every system can be migrated incrementally.
A hosting problem also deserves its own assessment. Moving a legacy app without a rewrite can establish a repeatable release process before changes to business logic begin.
What should the estimate make explicit?
An estimate should distinguish known work from unresolved assumptions. Ask for the discovery scope, first deliverable, acceptance checks, and the evidence that would change the estimate. A precise total without access to the code, data, or integrations gives you little basis for comparing proposals or managing the work later.
Compare these items across providers:
| Ask for | Evidence to look for |
|---|---|
| Behaviour coverage | Named workflows, sample inputs, expected outputs |
| Data transition | Trial migration, reconciliation checks, write ownership |
| Cutover | First users or traffic to move, failure conditions, responsible person |
| Recovery | Which changes can reverse and what happens to new records |
| Handover | Repository access, deployment instructions, operating owner |
Keep access to the source and release history throughout the engagement. A milestone should produce something your team can inspect and run. Specify how ongoing changes to the old application will be captured while the replacement is being built, or the two versions can drift before the first cutover.
What makes the handover complete?
The handover is complete when someone on your team can deploy a change, diagnose a failed release, and carry out the agreed recovery procedure. Ask the provider to demonstrate those actions from the documentation it delivers. A walkthrough led by the original author is useful; an independent repeat is stronger evidence.
Require database recovery to be demonstrated separately from application rollback. Starting an earlier image does not reverse data written by the new application. A rollback should not rebuild explains the release artifact you should retain, while the migration plan must account for schema and record compatibility.
A brief for comparing rewrite proposals
Send the same brief to each provider and ask for written answers tied to artifacts they will deliver. Leave unknowns visible instead of filling them with guesses. The resulting comparison should make the proposed first milestone clear enough that you can judge its value before approving the rest of the work.
LEGACY REWRITE PROCUREMENT BRIEF
Business constraint to remove:
Current application, repository, and operating owner:
Critical workflows and known exceptions:
Integrations, jobs, and reports that must keep working:
Data volume and permitted interruption:
PROVIDER RESPONSE
Evidence needed before recommending a rewrite:
Options: repair / partial replacement / full replacement
Reason for recommendation and assumptions still unverified:
Discovery deliverables and first working milestone:
Behaviour checks and person accepting the result:
Data migration rehearsal and reconciliation method:
Owner of writes while old and new systems coexist:
Cutover conditions and recovery procedure:
Source, deployment, and documentation handover:
Post-cutover operating owner and support scope:
Estimate, exclusions, and conditions that change it:
FAQ
How much do legacy app rewrite services cost? A useful estimate depends on verified scope: workflows, integrations, data migration, compatibility requirements, and the transition period. Ask providers to price discovery and the first bounded milestone, then state the assumptions behind any estimate for the remainder.
Should I hire a provider that recommends a rewrite immediately? Ask for the evidence behind the recommendation and an assessment of smaller alternatives. A rewrite may be justified, but the proposal should show why the existing application cannot meet the required outcome at an acceptable cost and risk.
Where does aidrop.it fit into a rewrite project? It provides the workspace and hosting workflow for code your team or coding agent delivers. Git repositories, explicit Service settings, build results, and logs help retain the operating record; they do not replace business discovery or data-migration design.
Bring a project that has history
Connect the repository you already have. aidrop reads its current revision, names the blockers instead of working around them, and builds the record the next person or agent needs. A project with history is not two clicks, and it is not sold as one.