Modernization of Legacy Applications
Modernize the application on which everything depends.
An in-house web CRM written in 2008, an Access database that handles billing, and a planning tool that a now-defunct vendor left behind without any documentation. These applications work—and that’s exactly what makes the decision so difficult. We’re taking them over, documenting them, and rebuilding them on a solid foundation—without interrupting production.
A legacy application does not stop working; rather, its environment is phased out on published dates. As of April 30, 2026, an application that sends emails using a username and password will no longer be able to do so. On October1, 2026, the EWS interface forExchange Online will be shut down by default. On January 12, 2027, Windows Server 2016 and .NET Framework 4.6.2 will reach end of support on the same day.
The schedule that determines
It is the ground beneath her that is aging.
Software written fifteen years ago does exactly the same thing today as it did yesterday. What has changed are the operating system, the database, the middleware, and the services it communicates with—and those have published end-of-support dates. Here they are, as announced by Microsoft.
April 30, 2026
Already over
July 14, 2026
Already over
October1, 2026
Weeks
November 10, 2026
Weeks
January 12, 2027
This year
April 2027
Next year
Around 2027
Keep an eye on
January 9, 2029
Horizon
At least 2,029
A Breather
These dates aren’t selling points— they’re scheduling constraints. They determine the order of the projects and rule out certain approaches—you can’t redevelop an application in ten weeks if its server is shutting down in January. That’s why our first step is an assessment, not an architectural proposal.
Locate My AppWhat are we talking about?
"Traditional" doesn't mean "old."
Age doesn't mean anything. We use 20-year-old applications that cost almost nothing, and we've taken over 5-year-old ones that were already unmanageable. What matters are these five signs —and just two of them are enough to warrant looking into the matter.
01
Only one person knows how to restart it
Knowledge resides in a person’s mind, not in a document. The day that person goes on vacation, changes jobs, or retires, the company realizes that it depends on that person —not on its software. This is the most common risk and the one for which the least provision has been made.
02
No one can say what's in it
No specifications, no up-to-date data schema, no list of business rules. Simple questions remain unanswered: How many active customers are there? Which rule determines this discount? Why does this field sometimes contain a date? An application that cannot be described cannot be audited or replaced.
03
Each upgrade costs more than the previous one
The cost of adding a field has doubled in three years. Every change breaks something else, so we don’t make changes anymore: we work around the problem using a spreadsheet, duplicate data entry, and manual processing on Fridays. The actual cost is no longer reflected on the IT invoice but is now spread across the business teams.
04
She is blocking another project
The migration server updates are pending, the transition to Microsoft 365 is on hold, and the replacement of workstations is on hold—because this application only works on this version of Windows, this version of the database, and this browser. It doesn’t cost much—it costs all the other projects.
05
It doesn't hold up in front of an auditor
No access logging, no change log, shared passwords, personal data stored indefinitely, and backups that have never actually been restored. The issue no longer comes from the IT department—it comes from a regulator, an insurer, a client who requires a security questionnaire, or data protection concerns.
The opposite is also true
An application that costs two days a year isn't being modernized.
If it does its job, doesn’t interfere with anything, can be managed by two people, and doesn’t store any sensitive data: we leave it alone and note the date when we’ll need to review it. This is a common conclusion of our audits, and we put it in writing. A service provider who finds a project in every application hasn’t conducted an audit—they’ve just provided a quote.
The Diagnosis
Five questions, and a path laid out.
There are seven ways to handle a legacy application, and six of them do not involve rewriting it. Answer five questions: we’ll tell you which approach we’d recommend, the key consideration that goes with it, and a comparable published case study . No contact information is required; nothing is sent, and nothing is recorded.
Answer the five questions.
The conclusion is written right here, on this page. There’s no address to go to in order to read it, and sometimes it tells you to do nothing.
The Trajectory
Keep — and secure the area around it
Probably nothing to rewrite.
Nothing is urgent: wise spending isn’t a project—it’s a dated assessment of the current state of affairs. We take inventory, document what no one else has written down, list end-of-life components along with their deadlines, and secure everything surrounding the application—backups that can actually be restored, role-based access, and logging. You’ll walk away with a roadmap and a timeline, not a construction site.
Relocation
Move it first, then decide.
A tight deadline and a service that can’t be shut down: the only reasonable course of action is to move the application off the server that’s about to shut down, without making any changes to it. It restarts as-is on a supported platform—virtual machines Azure or an upgraded on-premises infrastructure—complete with the necessary backups and monitoring. This doesn’t improve the application; it buys time to make the right decision.
Replatforming
Change the platform, keep the code.
This is the most common—and most underestimated—approach. We don’t rewrite the business logic: we rebuild the framework, migrate the database to a supported version or to Azure SQL, we replace the access methods that will be phased out, and we rebuild the delivery pipeline. The application provides the same service, on a foundation that will last another ten years, at a fraction of the cost of a rewrite.
Encapsulation
Lock it away behind an interface.
We don’t rewrite what we can’t read, and we don’t throw it away either as long as it’s still useful. We expose it properly through a documented web service, then build the new system around it: new features go through the interface, the old core continues to run, and it’s then replaced piece by piece. The rule that applies here, as everywhere else, is this: anything specific exists separately, outside the application that uses it and outside the system that consumes its results—and is therefore testable, versionable, and monitorable.
Replacement
A market-ready product—and the integration that goes with it.
If a product largely meets the need, developing a custom solution would be a waste of money —and we say this even though we know how to do it. The work then shifts to where it really belongs: the requirements specification, the comparative analysis of proposals, data integration, and interfaces with the rest of your system. That’s generally where these projects fail, not in the choice of product.
Redevelopment
Redevelop it in phases.
Either the requirement is specific to your line of work, or the application can no longer do what you’re asking it to do: you’ll have to write the code yourself. Most of the time, we don’t add a new platform —we build the business interface on Power Apps and Dataverse, the native foundation of Power Platform, with a single security framework and licenses we’ve already acquired. When a completely custom solution is needed, we build it from scratch: applications, portals, web services, and data processing. Never in a single release—but in short batches, each deployed to production.
Withdrawal
Maybe the question is whether to turn it off.
An application that’s expensive to maintain and whose shutdown wouldn’t bother anyone doesn’t need to be modernized— it needs to be properly decommissioned. This still takes work—identifying residual use cases, preserving data in a readable and searchable format for the legally required period, notifying the few remaining users, and shutting down the rest—but it’s a matter of a few weeks, not a project. We’d rather tell you this here than try to sell you something else.
Points to Watch For
Your email will fail before anything else.
This is the most dangerous dependency today, because it’s already outdated. Basic authentication for SMTP sending was deprecated as of April 30, 2026, and the EWS interface forExchange Online will be disabled by default on October1, 2026, and will be phased out in April 2027. Any application that sends messages or reads mailboxes must switch to modern authentication and use Microsoft Graph for reading. This isn’t just a matter of convenience—it’s a countdown.
The invisible interfaces will determine the schedule.
What’s connected to the application is almost never documented: a user’s spreadsheet that reads the database via ODBC, the copy tool that drops a file into a shared folder, the scheduled script running on a workstation under a desk, the nightly export to accounting. You won’t find this in the documentation—you’ll find it in the logs and network traffic. We look for these dependencies before estimating, because missing just one can push the go-live date back by a month.
This is the simplest case—and the one most often overlooked.
An application without a user interface is the easiest to migrate: no contracts to renegotiate with another system, no windows to coordinate. It’s also the one that gets overlooked in an inventory, precisely because it doesn’t communicate with anyone—until the day the server hosting it is decommissioned and a department discovers it can no longer edit its documents. So we first check who is actually using it—and how often.
Importing the data will be half the work.
Twenty years of unrestricted data entry results in duplicates, fields used for purposes other than their intended ones, codes whose meanings no one remembers anymore, and dates in free-form formats. We measure the actual data migration throughput before announcing a timeline, and if the measurement contradicts the timeline, the timeline is adjusted. The original copy is retained, each step can be retraced, and reconciliation is done with your users—not based on a technical report.
A comparable published mandate
Scripts and spreadsheets replaced by a platform Provisioning was done manually via PowerShell, the numbering plans were stored in Excel, and no off-the-shelf tool met our needs. We designed and developed it ourselves: more than 280 sites, a single portal, and provisioning time reduced from several hours to just a few minutes. Read the mandate Business applications migrated to Azure, including software vendors Local servers running at full capacity, business applications inaccessible remotely, and patient data subject to Swiss regulations. Compatibility was verified with each software vendor before any commitment was made, and the transition took place without interrupting operations. Read the mandate A foundation rebuilt without ever interrupting service When operations cannot be paused for even an hour, the approach is designed around that constraint—not the other way around: high availability, repeated dry runs, and no disruption for users. Read the mandate Two systems that were previously unaware of each other, now seamlessly connected The most common request we receive is to make existing systems communicate with each other—without replacing either side and without creating a dependency between service providers. Read the mandateThis conclusion is a preliminary assessment, not a commitment: we are not familiar with your code, your data, or your constraints. What we will send you next is a proposal for our services—scope, workload, timeline, and deliverables. Preparing the proposal is free; the audit is the first step in the engagement.
The Seven Trajectories
Rewriting is the last resort, not the first option.
Here are the seven possible outcomes, along with their approximate durations. The column that no one else mentions is the third one: what the trajectory doesn’t account for. That’s the one you should read first, because it’s the one that leads to unpleasant surprises six months down the road.
| The Trajectory | What it solves | What It Doesn't Solve | When It's the Right Choice |
|---|---|---|---|
| Keep it safe and secure the area around itA few weeks | The risk, without altering the software: backups that actually restore data, role-based access, logging, and written documentation where none existed before. | What this doesn't solve: Nothingof substance. The application remains as it is, and the deadline remains on the calendar. It's a deliberate delay, not a decision. | She's doing her job; she's not getting in the way; two people can handle her; and the deadline is still a long way off. |
| RemoveA few weeks | The cost, definitely. The data is retained in a readable and searchable format for the legally required period; the rest is deleted. | What It Doesn't Solve: Residual users—there are almost always three people who are still using it, and they don't say anything until after it's been shut down. You have to go find them before that happens. | The service has been discontinued, has been incorporated into another tool, or is now limited to archive lookups. |
| RelocateA few weeks | Server expiration. The application is deployed as-is on a supported platform— Azure or a renewed on-premises infrastructure—with backup and monitoring. | What It Doesn't Solve: Absolutelynothing about the application—same code, same technical debt, same dependence on a single person. And hosting costs may go up if the scaling is carried over as-is. | A deadline is coming up soon, and the service can't be interrupted. We're buying ourselves some time to make a proper decision. |
| ReplateformerA few months | The foundation: migrating the framework and database to a supported version or Azure SQL, replacement of deprecated access methods, and a rebuilt delivery pipeline. | What It Doesn't Solve: Usability issuesand missing features. Users will see the same screen —and they need to be told this beforehand; otherwise, the project will be perceived as a failure even though it was a success. | The business logic is correct, but the runtime environment is no longer. This is the most common scenario. |
| EncapsulateA few months | The lock-in. The application is exposed via a documented web service; new features are implemented through the interface, while the legacy core continues to run and can then be replaced piece by piece. | What It Doesn't Solve: Thecore, which remains. If the decision to replace it is never made, the interface becomes yet another layer to maintain —and the problem has doubled instead of going away. | Either the code is unreadable, or the application is too large to be processed all at once. In that case, modernization is carried out incrementally. |
| Replace with a productA few months | Maintenance of custom features, which is handled by a software vendor. And often features that no one would have paid to have developed. | What It Doesn't Solve: Your SpecificNeeds. The issue is never the product itself; it's the gaps: data migration, interfaces, and the five percent of business processes that don't fit into the tool and will have to be handled somewhere else. | One product more than meets the need. Developing a specific solution would therefore be a waste of money, and we're saying so. |
| RedevelopIn successive phases | Everything: the features, the usability, the base, traceability, and the ability to evolve without breaking. It’s also an opportunity to get rid of what’s no longer needed. | What It Doesn't Solve: The passage of time. The field continues to evolve —this is the first of the four pitfalls listed below, and it's what derails most rewrites. | Either the requirement is specific to your line of work, or the application can no longer perform the tasks it’s asked to do. Never in a single release: in small batches, each one deployed to production. |
These time frames are rough estimates, not guarantees: an app with three screens and one with three hundred have nothing in common. They help illustrate that there’s a ten-to-one difference between the first and last—and therefore that it’s worth making a choice before you start.
What Nobody Tells You
Four pitfalls—and none of them are technical.
They aren't included in any specifications, they easily account for half of the actual workload, and they are the reason we refuse to provide a cost estimate for a modernization project before we've assessed the existing conditions.
01
Functional Gel
During a rewrite, business operations continue as usual: new rates, new legal requirements, new clients demanding a specific format. If we freeze the old application, the new one will be released too late to meet business needs. If we don’t freeze it, we end up implementing the same changes twice—in both systems—for the entire duration of the project.
Our approach is structural, not moralizing: short phases, each put into production, and the suspension tied to the contract rather than to goodwill. A project divided into three ten-week phases never requires a two-year suspension.
02
Data Recovery
That’s half the workload, and it’s always that half that we forget to account for. Twenty years of unrestricted data entry result in duplicate entries, fields used for purposes other than their original intent, codes whose meanings no one understands anymore, dates in arbitrary formats, and amounts in two currencies with no indication of which is which.
We measure the actual throughput before announcing a schedule: it is this measurement—not the number of screens—that determines the duration of a switchover. We retain the original copy; each run can be replayed, and reconciliation is done with your users. If the measurement contradicts the schedule, the schedule is adjusted.
03
Invisible Integrations
A user’s spreadsheet that reads the database via ODBC. The file copier that saves a file to a network share. The scheduled script on a workstation in an office, whose author left in 2019. The nightly export to accounting, and the mailbox that the application checks every five minutes.
None of this is documented. It’s not in a set of specifications—it’s in the logs, in the scheduled tasks, and in the network flows. A single overlooked dependency pushes a handover back by a month—and it’s almost always that one that comes up on a Friday at 5 p.m.
04
Dependence on Another Person
The real risk is almost never the technology itself: it’s that the knowledge resides in a single person’s head, whether inside or outside the company. An application whose rules are understood by only one person is not a company asset; it’s an unspoken agreement with that person.
For us, documentation isn’t a deliverable at the end of the project —it’s the first one. And the project doesn’t end when the system goes live, but rather when we hand over the supporting documentation: documented architectural decisions, a completed acceptance test plan, and operations transferred to your teams or your regular service provider.
Our Approach
Five steps, five deliverables that you keep.
In this order, without skipping a step. Each step produces a document, a configuration, or a measurement— something that stays with you even if you stop us at the end of the step. Nothing is decided based solely on an estimate.
01
Inventory and Audit of the Current Situation
We look at what actually exists, not what the documentation says: the versions that are actually installed, the unsupported components and their dates, the data schema as it is, the volumes, and the dependencies that no one documents.
This is the step that most projects skip over, and it’s the one that determines everything else. Nothing gets started until this step is complete . This is also where we write when there isn’t a project to work on.
What We Deliver
- Application inventory: versions, platforms, licenses, volumes, number of actual users
- The Dependencies Map — Interfaces, Scheduled Tasks, Shares, Direct Database Access
- The reconstructed data schema and the business rules found in the code
- The due dates for each component, and the cost of each risk if it were to materialize
02
The decision, on a per-application basis
One path per application, chosen from among the seven—and not the same one for all of them. A set of twelve applications is generally handled using four different paths, at least one of which involves doing nothing.
Everything is documented before we even touch the first server, including the options we ruled out and why. An architectural decision whose rationale is unknown is replayed every time there’s a change in personnel.
What We Deliver
- The approach selected for each application, and the options that were ruled out along with the reasons for doing so
- The division into batches, each of which is put into production, along with the dependencies between them
- Batch-based estimation and the order dictated by media deadlines
- The contingency plan, written before the first shift and not during it
03
The foundation, then the first production feature
Before writing the second line: environments, the delivery pipeline, test suites, security, monitoring. Nothing is deployed to production manually.
Then a fully functional, end-to-end system that’s actually being used —not just a prototype. That’s the only real proof that the architecture holds up, and it comes at the beginning of the project rather than at the end.
What We Deliver
- The environments —development, testing, production—and the automated delivery pipeline
- Role-based access control, integrated with your directory Entra ID, and access logging
- Test cases and automated tests that protect what already exists
- A first feature in production, used by real people
04
Batch Switching
Each batch follows the same process: re-run of data that can be repeated, dual operation when possible, acceptance testing conducted with your users, and a detailed comparison of figures between the old and new systems.
The old system stays up and running until you confirm. It shuts down when you decide to, not when our schedule dictates.
What We Deliver
- Replayable data recovery, with the original copy preserved
- The Reconciliation Report: What Was Included, What Was Excluded, and Why
- The recipe book created in collaboration with your users, and signed
- Support for users during their first few days, provided by those who built the system
05
After that—and that’s where the value lies
There’s no point in modernizing if the application becomes unreadable again within three years. The final step is designed to prevent that from happening: up-to-date operational documentation, handover to your teams or your regular service provider, and the source code kept in-house.
We’ll then handle ongoing maintenance if you’d like—fixes, updates, and version upgrades— even on environments we didn’t set up ourselves. But we don’t plan to stick around: our goal is to ensure your teams can manage the tool on their own after we’re gone.
What We Deliver
- Operating documentation and technical documentation: submission and maintenance
- The source code and the data model: they're yours, with no dependency clauses
- Forwarding to your teams, or to your usual service provider, if you have one
- Fitness training with a guaranteed timeline, if you entrust it to us
Three types of contracts support this approach: the project-based flat-rate contract, when the scope can be defined in advance; the on-site staffing support, when you’re in charge but need extra hands—we’ve held a federal license for staffing services since 2018; and the service contract, when the goal is to take over and maintain operations over the long term. The type of contract is chosen during the scoping phase, not in advance.
Why Choose Us
Both professions, under one roof.
That’s the key difference when it comes to this specific issue. An integrator who doesn’t develop software has only one solution to offer: replacing the system with a product. A developer who isn’t familiar with the infrastructure underestimates the importance of the foundation, the identities, and operations. Modernization requires both types of expertise under one roof.
When the tool that would meet our needs doesn't exist on the market, we build it—and when it does exist, we say so. That's also why two of the seven paths on this page involve not undertaking a project.
1995
The year we started. Some of the apps we're taking over are newer than the company itself.
784
Completed implementation projects, from workstations to custom-developed platforms
+280
Websites connected to a platform that we designed and developed for a single client
What's included
- Two areas of expertise under one roof: infrastructure, identities, and operations on one side; design and development on the other. During a modernization project, the two teams communicate with each other every day.
- Taking over tasks that no one else can handle is part of our day-to-day work—in fact, it’s often what brings us to a client in the first place, even before any project begins.
- The source code and data are yours, along with the data model and documentation. There is no clause requiring you to come back.
- On-site teams: Renens, Sion, Châtel-Saint-Denis. No one opens a ticket on the other side of the world on the night of a switchover.
- Federal authorization for staffing services since 2018: We can also assign a developer or architect to your team for the duration of the project.
- A Microsoft Partner for sixteen consecutive years: Azure, Power Platform, Dynamics 365, Microsoft 365. Modernization almost always falls into one of these four categories.
Frequently Asked Questions
What we're asked to do before we begin.
The questions that come up on every first date, with specific answers. A vague answer at this stage doesn't help anyone —and doesn't let us compare you to someone else.
Do we have to rewrite everything?
Almost never. Of the seven possible approaches, six do not involve rewriting: maintaining and securing the existing system, removing it, rehosting it, replatforming it, encapsulating it, or replacing it with an off-the-shelf product. A complete rewrite is the most time-consuming and risky option; it is justified only when the requirement is specific to your business and the application can no longer perform the tasks required of it.
In a suite of multiple applications, the usual conclusion combines four different paths, at least one of which involves doing nothing.
How long does it take?
An application scope audit takes weeks, not months. After that, it all depends on the path forward: migration takes weeks, refactoring or encapsulation takes months, and redevelopment takes place in batches of a few weeks each, with each batch being deployed to production.
We don't announce a timeline until we've assessed two things: the actual data recovery throughput and the number of dependencies to be addressed. These factors determine the duration much more than the number of screens.
Is the audit free?
No, and we prefer to be clear about this. The proposal is free: it includesthe scope, workload, timeline, and written deliverables, with no obligation on your part. The audit, however, is the first step of the engagement —that’s where the work begins, and it’s a deliverable that you keep.
A service provider offering the audit bills you separately for it, or plans to recoup the cost through a project they’ve already secured before you’ve even had a chance to understand it. We prefer to sell you a short, useful phase, at the end of which you can choose to stop working with us.
What if the original service provider is no longer in business, and there is no code or documentation?
This is a common scenario, and it alters the trajectory rather than blocking it. You don’t rewrite what you can’t read—you observe it. Business rules are found in the data, in the logs, in printed reports, and in what your users know.
The usual solution isencapsulation: the application is exposed through a documented interface; the new code is built around it, and the old core is then replaced piece by piece. In some cases, the database alone is enough to reconstruct what matters.
Do you ever take on an app that you didn't write yourself?
Yes, and that’s often what brings us to a client’s site in the first place, even before a project begins. We provide Level 2 and Level 3 support for environments and applications that we didn’t build ourselves, with a commitment to timely response.
It always starts with a recovery phase: understanding, documenting, and securing access and backups. This phase comes at a cost, and it has an end.
Should we go to the cloud ?
No, not necessarily, and claiming otherwise does no one any favors. Sticking with a local infrastructure remains the right choice when data location requires it, when the network is isolated, when industrial or medical equipment cannot be moved, or when the cost of hosting a system modeled after the existing one would exceed the cost of the hardware itself.
What is no longer tenable is to remain on an unsupported platform and hope that things will work out. In between, there are hybrid approaches: local applications, data stored in Azure, identity and access in Microsoft 365.
What technologies are you working on?
For applications and business interfaces: Power Apps model-driven, Dataverse, Power Automate , and Dynamics 365 — the native foundation, requiring no additional connectors or parallel security measures, with licenses often already in place. For services and processing: Azure Functions, Logic Apps, Service Bus, API Management, Azure SQL, Data Lake, and data gateways to on-premises environments.
And fully customized solutions when needed: applications, portals, extensions, web services, and calculation engines. The form follows the need—never the other way around.
We don't have an in-house IT team. Is that a problem?
No, but that changes the scope of the contract. It then includes what no one else will handle for you: documentation, the handoff to your regular service provider (if you have one), and post-launch support.
A fair point: if your organization has fewer than 100 employees and no IT resources, a local partner—one you can reach within an hour if a workstation isn’t booting up—will serve you better on a day-to-day basis. We remain focused on the project itself; we don’t replace that local presence.
We want artificial intelligence to analyze our data. Should we modernize first?
Yes, and in that order. An application whose data is locked into a proprietary format—with no access interface, no documented schema, and no fine-grained permission management—is useless for anything: not for a wizard, not for a dashboard, and not even for a simple, reliable export.
Presenting the data clearly is the first step, and it’s a project in itself —often the best first step, because it also supports everything else. The first question to ask isn’t “which model,” but “who has the right to see what, and how can we prove it?”
How do you avoid making us dependent on you?
Deliverables, not promises. The source code, data model, and technical documentation are yours, with no dependency clauses. Architectural decisions are documented along with their rationale. The delivery process is automated and documented: another service provider should be able to take over.
And the contract doesn't end when the system goes live: it ends with the handover of the evidence and the transfer. That's stated in the proposal, not in a conversation.
Related Topics
What modernization always encounters.
An app doesn't stand alone: it touches on the foundation, identities, messaging, and data. Here are the other building blocks we're putting in place, and where you can read our published mandates.
Continued
Let's talk about your app.
A few lines are all it takes to get started: what she does, what she’s going through, and what concerns you. We’ll tell you about similar cases we’ve handled, the approach we’d recommend, and how we could help. The proposal is free of charge—covering scope, workload, timeline, and deliverables—with no obligation on your part. The audit, meanwhile, is the first step in the engagement—that’s where the work begins.