You know the old system has to change. It might be a VB6 desktop app, an early .NET or PHP build, or an Access database that grew into the core of the business. Every quote sounds confident, and none explains how your orders, invoices or stock records will survive the move.
The vendor you pick decides most of the risk. A good legacy modernization partner keeps the business running while the system changes underneath it, proves the data arrived intact, and hands you code and documentation you can take anywhere. Below are the questions that separate that partner from the rest, a checklist for your shortlist and the red flags.
Why the partner matters more than the technology
Old platforms do not age gracefully. Microsoft stopped supporting the Visual Basic 6 development environment on April 8, 2008 and recommends replacing VB6 applications with modern technology. PHP gives each release branch two years of full support and two more of security fixes only, after which it reaches end of life. If your system runs on either, the clock started long ago.
Picking a new stack is the easy part. The hard part is understanding undocumented rules, moving years of records and switching users over without a bad week. BCG found that 70% of the digital change efforts it studied fell short of their objectives. If you are still deciding whether to act at all, start with the signs your legacy system needs modernization.
Ask for discovery before a quote
A vendor who quotes a fixed price after one call is guessing. Old systems hold rules nobody wrote down: a discount that applies only on Fridays, a field that means two things.
A sound partner proposes a short discovery phase first. You should receive:
A code and database assessment: languages, frameworks, versions, third-party components and their support status.
A map of what the system does: screens, reports, scheduled jobs and every integration with other software.
A list of risks and unknowns, each with how it will be resolved.
A phased plan and a quote built on all of the above, with clear assumptions.
Ask how the business keeps running during cutover
This matters most to a COO. The answer should be a staged plan, never one weekend switch for the whole company.
Listen for specifics. Which module moves first, and why? Will old and new run side by side, and how are records kept in step? What is the rollback plan, and who decides to use it?
Many teams replace a system one piece at a time, an approach we explain in modernizing old software without a full rewrite.
Each stage should prove itself with real users before the next starts, so a problem affects one area briefly, not the whole business.
Ask how your data will move and be checked
Data migration is where quiet damage happens. Missing fields, duplicate customers and old codes all need a decision before they move.
Mapping: a written map from every old table and field to its new home, signed off by your team.
Cleansing: an agreed rule for each known problem, such as merging duplicates or flagging incomplete records.
Rehearsals: at least one full trial migration on a copy of live data before the real one.
Verification: record counts, totals and sample checks compared between old and new, with the results shared with you.
Ask to see a verification report from a past project.
Ask how they test that nothing broke
Your users judge the new system on one thing: does it give the same answers as the old one? A good partner records real inputs and outputs first, such as invoices, stock movements and report totals, then runs the new system against them automatically.
For the engineering reader, ask about regression tests, how test data is drawn from production without exposing personal records, and who signs off each release. Plan user acceptance testing around your staff's time, not in the final week.
Ask what you own at the end
A modernization that leaves you dependent on one vendor has only moved the risk. Get these in writing:
Code ownership: you own the source code, and it lives in a repository you control from the first day.
Documentation: architecture notes, deployment steps and the business rules found during discovery.
Handover: sessions that walk your team or a future vendor through the system.
Confidentiality: an NDA signed before you share code, data or process details.
Ask who will actually do the work
The people in the sales meeting are often not the people who write the code. Ask to meet the lead who will run your project and how much of their time is committed to it.
Then ask for references from similar work: a comparable system, such as an old desktop app or a database-heavy business tool, matters more than a comparable industry. Ask the reference how cutover went.
Red flags when choosing a legacy modernization partner
A big-bang rewrite promise: rebuilding everything and switching over in one go, with no staged releases.
A fixed price before discovery: the number came before anyone read your code.
No data verification plan: migration is described as "importing the data".
Vague ownership terms: code held in the vendor's accounts, or a license instead of full rights.
No named team: you cannot meet the people who will do the work.
A question checklist for your shortlist
Take this table into every vendor meeting.
Area | Question to ask | A good answer includes |
|---|---|---|
Discovery | What do you need to see before you can quote? | Code, database and user access; a written assessment and phased plan |
Continuity | How will we keep trading during cutover? | Staged releases, a parallel run where needed, a tested rollback plan |
Data | How will you prove our data arrived intact? | Field mapping, trial migrations, counts and totals reconciled and shared |
Testing | How will you know the new system gives the same answers? | Old behavior captured as automated tests; planned user acceptance testing |
Ownership | Who owns the code and where does it live? | You own it, in your repository, from the first day |
Handover | What will we receive at the end? | Architecture notes, deployment steps, business rules written down, handover sessions |
Confidentiality | When do you sign an NDA? | Before any code or data is shared |
People | Who will lead the work day to day? | A named lead you have met, with committed time |
Proof | Can we speak to a client with a similar system? | A reference for comparable technology and a cutover they can describe |
How we answer these questions
At iTechnoSol, the first call is with a founder, and the NDA comes before anything else. You own all the code we write. Every legacy system modernization project starts with an assessment of what you run today, then moves in stages so the business keeps working.
One example: a news publisher came to us running stories through a patchwork of separate tools. We replaced them with a single publishing system for web and mobile apps, and moved more than five years of published stories across from the old platform. You can read how that project ran. If you are not ready to commit to a build, our software consultancy team can run the assessment on its own.
Choose the partner that shows its working
The right legacy modernization partner earns your trust before the contract: it reads your code before quoting, explains how you keep trading during cutover, proves your data arrived intact and leaves you owning everything it built. When you want to put the same questions to us, book a call and talk it through with a founder.
