A system in service needs upkeep, not a rebuild
Delivered software is not finished. It is used, so it moves: a rule changes, a channel opens, a team reorganises, a component needs updating. Without upkeep, the gap widens until the day nobody dares touch it any more.
That is most often when we are called: a system that still runs, whose original supplier is no longer reachable, and whose documentation does not exist. We take it over, we document it and we maintain it, rather than offering to rewrite it.
Application support is not just a number to call. It is someone who knows your installation, who restores the service and then looks for the cause, and who tells you what happened in plain language rather than jargon.
We start with an inventory of what exists: where the code is, where the data is, who holds the access, what has been configured and what has been developed. This stocktake is written down, because it is what goes missing when a supplier leaves.
After that, the work is continuous rather than cut into large projects. Requests come in as tickets, we handle what is raised, we flag what is going to cause trouble, and each time we separate what can be configured — which you will be able to redo yourself — from what needs development.
Inventory of what exists
Where the code is, where the data is, who holds the access, what has been configured and what has been developed
Takeover and documentation
We write down what we find and we secure what needs securing
Continuous maintenance
Fixes, updates and monitoring, with requests tracked as tickets
Enhancements
Functions added as use reveals them, configuration first
Application support and maintenance covers business applications, online sales platforms, portals and content sites: fixing faults, functional enhancements, security updates and version upgrades.
To these are added the projects that come round regularly: migration to a new version, a new platform or a new host, taking over a project whose knowledge nobody holds any more, interconnection with the other tools in the house, and hosting.
The same technologies, once they are running
What we build, we know how to look after — and we also take on what we did not build. That is in fact the common case: a system delivered years ago, whose original supplier is no longer reachable, that nobody dares touch. Open source helps here: the code is readable, the data is accessible, and nothing is locked behind a licence that would forbid looking.
The platforms in service
Odoo, Dolibarr, ERPNext, PrestaShop, Magento, SuiteCRM, Vtiger, websites and content platforms, Pimcore, Strapi, Matomo, Google Analytics, Microsoft 365
We run the same building blocks we integrate: operations, online sales, sales follow-up, content and repositories, measurement, the workplace. Knowing them from the build side changes what you notice in service: a slow product repository or an order stuck in orchestration is diagnosed far faster when you know how these platforms are put together.
Application maintenance
This is the underlying arrangement: someone knows your system and stays available. We keep the knowledge of your installation current — what was configured, what was built, why a given decision was taken — because that memory is exactly what goes missing when a supplier leaves. We watch the alerts, deal with what comes up, and flag what is going to become a problem before it does. What changes for you: you no longer have to explain your own system at the start of every job.
Support
An incident has two stages that should not be confused: restore the service, then understand why it fell over. We do both, and we write the second down — otherwise the same incident comes back. We monitor what needs monitoring, we fix, and we tell you what happened in plain language rather than jargon. We do not promise a contractual response time: we would rather tell you what we are seeing and what we are doing than hold to a written commitment that says nothing about how well the work is done.
Enhancements
A system in use moves. A rule changes, a channel opens, a team reorganises, and what suited you at the start no longer does. We add functions as use reveals the need, discussing each time what can be configured — which you will be able to repeat yourself — and what has to be built. We deliberately push towards the configurable: less code means less dependence on us. What changes: the system follows your business instead of holding it back.
Updates
This is the subject everyone postpones until it becomes urgent. We track the versions of the platforms and their components, apply security fixes, and move up versions by first checking what the work makes of it. This is where the build rule pays off: a component grafted on cleanly moves up with the platform, whereas a fork of the product is paid for at every release. What changes: updates go back to being routine rather than a project.
Migrations
Changing major version, platform or host always comes down to one question: will the data arrive intact on the other side. We inventory what has to move, rehearse the migration on a copy until it runs without surprises, compare the data sets before and after, and prepare the way back before switching over, not after. The switch itself is the least interesting moment: everything is settled in the rehearsals.
Taking over an existing project
You inherit a system with no documentation, incomplete access, and sometimes no clear idea which server it runs on. We start with the inventory: where the code is, where the data is, who holds the credentials, what has been changed relative to the standard. We document what we find, secure what needs securing, then tell you plainly what can be kept and what should be replaced. Sometimes the honest answer is that a part cannot be salvaged; we say so rather than paper over it.
System interconnection
In service, the flows break first: a format changes at one end and the synchronisation stops without anyone noticing for days. We instrument the exchanges so that an interrupted flow announces itself, replay what did not get through, and revisit the question of data authority whenever a new tool arrives. That is what keeps core system urbanisation, clinical interoperability and BIM construction site monitoring working over time.
Hosting
Cloud infrastructure, dedicated infrastructure, Swiss data sovereignty, French data sovereignty
The choice is not made on a specification sheet, it is made on your constraints. Cloud infrastructure suits variable load, where capacity has to be adjusted without ordering hardware. Dedicated infrastructure is the answer when performance has to be constant, or when an audit requires knowing precisely where each thing runs. Swiss data sovereignty and French data sovereignty answer a question that is not technical at all: which law applies to your data, and who can reach it. We ask that question at the start, because it is expensive to deal with later.
The same person you spoke to on day one, still reachable.
A typical situation
An application delivered a few years ago still works, but nobody quite knows how any more. Fixes pile up, updates are postponed, and each intervention grows riskier than the last. We take the existing system over, document it, and keep it running over time rather than rewriting it.
Your requests go through a written trail: each one is logged, tracked and closed. On the other side, a single point of contact you can reach, who knows your installation and to whom you do not have to explain it again at every intervention.
Application maintenance covers three registers: fixing what goes wrong, evolving what use calls for, and preventing what is about to break — security updates, version upgrades, monitoring. We write down what we find, so that the knowledge of your system stays with you.
How long does it take to see concrete results?
Performance fixes show quickly; functional enhancements take longer. We set the timing against your existing system, once it has been taken over and documented.
How do you handle continuity of service during the work?
We work in stages, with test environments and maintenance windows agreed in advance.