Legacy application modernization that keeps what works

Often it doesn't. A rebuild is one of several modernization strategies and only pays off when further development and refactoring are clearly going to cost more. So we assess what's there first:

• Architecture, code quality and technical debt
• Effort per new requirement compared with building new
• Risk to ongoing operations
• Existing tests and documentation

Only then do we make a recommendation, even if it argues against a rebuild.

We regularly work with aging PHP applications (Symfony, Laravel, Zend and homegrown code), Java / Spring systems, Node.js and Python backends, and older frontends built on jQuery or Angular. On the data side: MySQL / MariaDB, PostgreSQL, MS SQL and Oracle.

• Access matters more than the technology: we need to see the source code, database schema and interfaces
• A working environment, even a test copy, speeds up the analysis considerably
• For systems without source code access or with binaries only, we check up front whether an analysis is feasible

If your source technology isn't listed, we clarify feasibility in the free intro call, before any costs come up.

It depends on the condition and size of the legacy system. As a guide from our projects:

• Software Audit: two weeks for a fixed price of €3,000 to €6,000
• Analysis phase in the project: about two to four weeks
• Target picture and architecture decision: about one to two weeks
• Implementation: varies widely by project. We replace in increments, not in one block
• Cutover with parallel operation and data migration: typically four to eight weeks

We only give firm numbers for your system after the assessment. Before that, it would be a guess.

Much less than with a traditional requirements process, because we reconstruct the feature set from the system itself instead of asking for it. What we need from you:

• Access to source code, database and a test environment
• One person for business questions, usually a few hours per week
• Occasionally, business users to clarify which workflows are really used and which aren't anymore
• Sign-off on each increment

Your team's biggest contribution is making business decisions, not gathering documentation.

Yes. We avoid the risky full swap on a single date and work step by step, using the strangler pattern:

• The new system takes over area by area, and the old one stays in production until then
• Old and new run in parallel until the new system has proven itself
• Data migration in controlled iterations with data integrity checks
• Before each cutover step, we define how far back you can roll

This reduces operational risk considerably. No migration of a production system is completely risk-free: once data has been changed in the new system, going back is a data question and has to be thought through in advance. That is part of our planning.

We don't reconstruct the feature set from memory. We capture it systematically and then verify it:

• Systematic capture of features, business rules and roles from the source code
• Comparison with the workflows your employees actually use
• Functional comparison between the old and new system
• Automated tests that lock in the expected behavior for good

AI mainly speeds up understanding and implementation. It doesn't make decisions:

• AI-assisted analysis of large, aging codebases
• Reverse engineering and extracting business logic from poorly documented code
• Dependency analysis between modules, database and third-party systems
• Generating tests, migrating code and documenting the feature set

Our developers own architecture, security, business correctness and code reviews.

We settle this in writing before the project starts, because for business-critical systems it's the key prerequisite:

• We work under an NDA. How source code and data are handled is set out in the contract
• For code analysis we use tools and plans where content is not used to train models
• We disclose up front which services we use and agree on them with you. You can exclude any of them
• Production data doesn't go into the analysis: we work with source code, schemas and, where needed, anonymized or synthetic test data
• If you require EU data processing or an on-premises setup, we set things up accordingly

If your compliance rules rule out AI, that doesn't rule out the project. The analysis takes longer, but the approach stays the same.

The Software Audit takes two weeks at a fixed price of €3,000 to €6,000 and ends with results handed over to you, not with a sales pitch:

• An audit report assessing the current state, readable without an IT background
• Prioritized risks and quick improvements
• A target picture and a reasoned recommendation for the right modernization strategy
• A roadmap with realistic sequencing and effort range
• A final presentation where we walk you through the results

The results belong to you and stay useful even if you implement them in-house or with another vendor.

The goal is a system that your team or another vendor can carry on with, not a new dependency:

• You own the source code. Repository, deployment pipeline and infrastructure are handed over
• Automated tests document the expected behavior and make later changes safe
• Architecture and operations documentation is written during the project, not afterward
• Training for your team or your future vendor is part of the handover

If you like, we take on operations and ongoing development beyond that, with proactive monitoring, managed deployments and named contacts. More under Custom software development and Cloud & DevOps.

An honest number is only possible after the assessment, because the effort depends almost entirely on the condition of the legacy system. That's why we keep the first step small:

• Intro call: free, 30 minutes, to clarify the situation
• Software Audit: two weeks for a fixed price of €3,000 to €6,000, with report, recommendation and roadmap
• Implementation: only after that, based on the sequencing and effort range from the audit

The effort range for implementation is part of the audit results. So you decide based on numbers, not a shot in the dark.