An Access file keeping the business running. A VB6 application nobody dares touch. A WordPress site from 2009 that breaks again every month. We help you pragmatically replace or upgrade old software, preserving the business logic that has crept in over the years.
The developer who built it left long ago. The documentation consists of a handful of screenshots in a shared folder. A few colleagues know exactly which button not to press on Thursday mornings. Yet the business relies heavily on that application — invoicing, stock, customer data, or the entire core process runs through it.
Modernising therefore starts not with code, but with understanding. We want to know what the software does, who uses it, and what would become impossible if it went offline tomorrow. Only then do we look at the building blocks: replace, upgrade, move to the cloud, or perhaps retire altogether. For organisations with a broader, messier IT landscape, we tackle this question together with an IT modernisation consultant who looks beyond this one application.
We mainly work on web applications and business software at the scale of Dutch small and medium-sized businesses and mid-sized organisations. No multi-year mainframe migrations, but concrete projects that deliver tangible results within one or two years. For the heavier end, we refer to our page on legacy software modernisation, where we go deeper into enterprise modernisation and strangler fig architecture.
The legacy software we typically encounter spans several generations of technology. On the desktop side we see Visual Basic 6, Delphi and older .NET versions. On the web side, Classic ASP, PHP 5, jQuery-driven sites on outdated frameworks, and WordPress installations from the early 2010s. In the office, these are often MS Access databases and Excel VBA files that have grown heavier over the years. On the business software side we see Oracle Forms, D2K and industry-specific packages on AS/400 or RPG. And sometimes there are remnants of Flash, Silverlight or Java applets that were officially deprecated in 2017, 2020 and 2021 but are still in everyday use. All of these share the same basic approach; only the migration route differs.
Not every legacy application needs to be rebuilt from scratch. Together we choose the route that fits your situation, based on business risk, user base, and how deeply the software is woven into other processes.
For applications that do what they need to do functionally, but run on an outdated stack. Think of a PHP 5 web application being brought up to PHP 8 and a modern framework, or a WordPress 3.x site going headless while keeping the same editorial workflow. The business logic stays, the foundation is renewed. This closely relates to the resolving technical debt service we also offer on its own.
For desktop applications or heavily outdated web software where the stack itself is no longer sustainable. We rebuild the core functionality in React, Vue or Astro with a REST or GraphQL backend, and migrate the data from the old system. Often using a strangler fig approach: replacing modules one by one while the old system is still running.
Sometimes rebuilding isn't the right route. If an existing SaaS package already covers 80 per cent of the functionality, we'll help you establish that honestly, select the package and guide the transition. We only build the parts that are truly distinctive: an integration, a dashboard, or a specific workflow piece.
Alongside working software, we want your organisation to be able to maintain the new environment itself, or have another agency maintain it without lock-in.
Four patterns we often see among organisations that approach us. If you recognise one or more of them, it's worth having a conversation.
The software still works, but nobody in the organisation knows exactly how any more. With every change there is fear that something will quietly break. It's no longer about moving forward; it's about balancing.
PHP 5, old .NET versions, Windows Server 2008, Flash, Silverlight, Java applets. The runtime is no longer maintained, security patches are no longer released, and your IT provider refuses to host it.
What worked in 2008 for 20 users now struggles under 200. Reports take an hour to run. Opening a new branch requires a manual database copy. Growth is held back by technology.
Three applications, three technology stacks, three versions of the truth about the same customer. Modernisation is then often also consolidation: fewer systems, better aligned with one another. This frequently forms part of a broader enterprise software project serving several departments at once.
A few recognisable scenarios that illustrate our pragmatic approach. We don't invent client names, but we do describe patterns we encounter time and again, so you can judge whether your situation is a variant of one of them.
An MS Access file originally built by an internal employee grows into the beating heart of a department. Backups consist of copied files on a network drive. We migrate the data to PostgreSQL, build a web interface with role-based access, and ensure every change is traceable via an audit log. The business logic is extracted from the existing forms and macros, validated with the users.
A Visual Basic 6 application that the entire back office uses every day. Installing it on new workstations is becoming harder, remote working is difficult, and the vendor of the old database has stopped supporting it. We build a React or Vue front end on a REST API, replace the old database with a modern equivalent, and connect the existing integrations through clearly documented interfaces. The user interface follows the original flow as closely as possible so that training stays brief.
A corporate website from the early 2010s running on an outdated WordPress version. The editorial team is used to the admin panel, but the site is slow, hard to keep secure and struggling under modern SEO requirements. We deploy WordPress as a headless CMS behind an Astro or Next.js frontend, keep the editorial workflow intact, and gain speed, security and build quality. Content moves across one-to-one.
An Excel file with VBA macros that production or administration depends on. A single faulty cell or a forgotten column can disrupt the whole chain. We convert the logic into a web form with server-side validation, link the outcome to your existing systems, and keep a record of every version entered. Excel remains available for standalone calculations where that makes sense, but the business process no longer runs on a single file.
Alongside the technical work, every modernisation project runs up against your organisation's policies and the regulations of your sector. We think along with you, not as lawyers, but as builders who understand how to translate these requirements into practice.
During modernisation it often becomes clear that the old application holds more personal data than is strictly necessary. We help with a privacy check on the data, decide together what should be carried over and what can be cleaned up, and document how data is processed and stored in the new environment.
Government bodies (Baseline Informatiebeveiliging Overheid) and organisations in critical sectors (NIS2) face stricter requirements for logging, access control and incident response. We build these requirements into the design and deliver documentation that aligns with your own ISMS.
When modernising healthcare software, we work in accordance with NEN 7510. Patient data remains within Dutch or European hosting, audit logs are standard, and authorisations are demonstrable at the level of the individual user.
If your organisation is ISO 27001 certified, we deliver documentation and processes that fit within your existing management system. No separate security silos, just an extension of what is already in place.
We map out what the application does, who uses it day to day and which invisible business rules are built into it. A few conversations with the people who truly know the software save many surprises later.
We lay out what it costs to keep the current application running for years to come, covering licences, hosting, external suppliers, security risks and loss of productivity, against the investment in modernisation. That turns it into a business decision rather than a gut feeling.
We determine the best route for each module. Not everything needs to be overhauled. Sometimes a module is already fine and only needs a hosting migration; sometimes it has to be rebuilt entirely; and sometimes it can simply be dropped because nobody uses it any more.
We start with a module that is manageable in scope but where success is tangible for the organisation. That builds confidence, delivers a working example, and surfaces unknown risks early.
Module by module, we build the rest while the old system is still running. Users experience a gradual transition rather than a big-bang weekend. Strangler-fig in practice, with validation after every release.
The data is cleaned, validated and migrated. Users receive training and a short transition period in which the old and new systems run side by side, so they can get comfortable with the new environment safely.
A runbook for incidents, monitoring with clear thresholds, and clear agreements about who does what. Whether we continue to run the system ourselves or you take it over in-house is entirely up to you, as long as it is properly owned.
What clients usually want to know first in a conversation about modernisation.
A thirty-minute introductory call, no obligation. We listen to what's running now, which headaches it's causing, and which direction makes sense. No sales pitch, just an honest picture of what's realistic. After that, you can decide for yourself whether it's worth continuing the conversation.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
