How to Choose a Legacy Modernization Partner

What you are really hiring a modernization partner to do

Modernization is less about new technology than about moving a working business onto it without losing anything. The old system may look dated, but it calculates commissions correctly, prints the exact report the auditor expects, and drops a file every night that another department imports at 6 a.m. A partner who sees only outdated screens will miss those obligations. Tepia starts every modernization by listing what the current system does for each department, including the things nobody remembers asking for.

The job has three parts. First, discovery of rules and dependencies: stored procedures, batch jobs, file drops, ODBC connections from Excel, and the one power user who exports data every Friday. Second, a staged plan that replaces the system piece by piece, often with what engineers call the strangler fig pattern, where new services take over one function at a time behind a stable interface. Third, a migration that preserves history and proves the numbers match.

Match the strategy to each part of the system

Ask every candidate to recommend a strategy per module, not one answer for the whole estate. Tepia uses a matrix like this during Discovery.

Most real plans mix three or four of these. For more depth, see how to modernize a legacy system and rebuild or refactor your app.

Evidence to ask for before you hire

Modernization partners should be able to show their method on paper. Ask each candidate for the following, and expect Tepia to provide the same.

• A sample assessment from a past project, with names removed, showing how modules and dependencies were scored.
• A migration rehearsal plan listing record counts, control totals and who approves each rehearsal.
• A parallel run approach that compares old and new outputs for the same inputs over a defined period.
• A rollback plan for each release, including how data written in the new system flows back if needed.
• Experience with your stack: VB6, classic ASP, older .NET Framework, Microsoft Access, FoxPro, AS400 green screens or COBOL batch jobs.

Tepia covers specific stacks on VB6 and legacy .NET modernization and mainframe and AS400 front end modernization.

How Tepia approaches legacy modernization

1. Discovery: code and database review, interviews with power users and the people who run month end, and a review of every integration, file drop and scheduled job. Deliverables are an Investigation Summary with a module by module strategy, an Interview Summary and User Stories that preserve current behavior.
2. Design: a design questionnaire, a style guide for the new screens, and wireframes that keep familiar workflows recognizable so trained staff do not relearn everything at once.
3. Development and Testing: Alpha and Beta releases per module, with characterization tests built from current outputs, user acceptance by the affected departments, and non functional tests for load and batch windows.
4. Training: hands on sessions that show users where each old screen’s task now lives.
5. Launch: rehearsed data migration, a parallel run, transition from the old system one function at a time, and support reps during each cutover.
6. Support: issue resolution, bug tracking and feature requests once the old system is retired, plus cloud migration work where it is still needed.

Each stage typically moves through Discovery in 1 to 3 months and development in 2 to 6 months, and later modules tend to move faster. See our process.

Start with a scoped assessment, not the whole program

You do not have to choose a partner for a multi year program on the strength of a few meetings. A better approach is to commission a bounded assessment first: a few weeks to review code, databases, integrations and users, ending in a written module by module plan. The assessment gives you something concrete to judge, and it gives the partner real information to plan from instead of guesses. Tepia runs this as the opening part of Discovery.

Use the assessment to test the relationship as much as the plan. Did the partner find rules or dependencies your own team had forgotten? Did they explain technical risk in language your finance and operations leaders understood? Did they push back on any part of your assumptions, such as the idea that everything must move to the cloud at once? Did they identify a first module that could deliver value early, such as a mobile front end for field staff over the existing core?

If the answers are yes, you have a partner worth continuing with. If the assessment reads like a sales document, you have learned that early, before the real work began.

Warning signs in modernization proposals

Tepia often reviews proposals buyers received elsewhere. These patterns predict trouble:

• A single big bang cutover date for the whole system, with no staged releases.
• Automatic conversion promises claiming a tool will translate the entire codebase into a modern language with no rework.
• No rule inventory or plan to capture behavior before changing it.
• Reports treated as an afterthought, even though finance and compliance teams depend on them.
• Integrations missing from the plan, especially file based ones other departments quietly rely on.
• Silence on data quality, when old systems always hold duplicates, orphaned rows and free text in numeric fields.

If a proposal on your desk shows two or more of these, ask for a revised plan or ask Tepia for a second opinion.

Frequently asked questions