A new system built around your process, connecting the systems already in use, or modernising a core that no longer keeps up, with maintenance after implementation.
See the serviceModernising systems already in use
Your system rebuilt one part at a time without stopping work: knowledge of it recorded in tests, components on supported versions and code that can be changed.
Scope
What clients come to us with
One person knows how the system works
The program was written by a former contractor or by an employee who is still with the company. Only that person knows why the system calculates a discount the way it does, and their departure would leave the company with code nobody reads.
The vendor no longer supports the version the system runs on
The database, the operating system or ready-made code components from other vendors are on versions that no longer receive fixes, including security fixes. A newer version will not accept the old code without changes, and nobody wants to touch the code, because nobody knows what will stop working.
Every change takes a long time, and the system is slowing down
A new price list or a field in a form waits a long time, because the code is tangled: a fix in one place changes behaviour in another. People check changes by hand, and as the volume of data grows the system slows down and the company works around it with spreadsheets.
Scope
What we do
Modernisation is the rebuilding of a working system one part at a time. First we break it down into parts: data, rules (the code that calculates prices and deadlines), screens, connections to other systems, and the components it all rests on, such as the database version and the servers. We decide on each part separately: it stays, is replaced or is moved to a supported version.
What stays, what we replace
Data almost always stays; we move it to a database version for which the vendor issues fixes. We update unsupported components first, because the rest rests on them. We replace rules one at a time, according to the number of changes waiting behind each, and screens where they slow work down. We leave the connections to other systems as they are; bringing them together into one place for data exchange is a separate scope.
Before we touch the code, we surround it with automated tests: programs that record how the system responds today to each type of case and check it after every change. Knowledge of the rules moves from one person's memory into the tests; that person reads the code with us and explains each rule. Refactoring, rebuilding code without changing what the system does, means a change in one place stops breaking others. Where the system slows down, we rebuild for scalability, that is, handling more traffic.
Old and new side by side
We launch the new part alongside the old one, on the same data, so the old system sees everything the new one writes. Between them sits a switch: a setting that routes a given function to the old or the new code without installing a new version. For an agreed period both versions calculate the same thing and we compare the results. We switch the old code off when the differences disappear, and if the new part fails, the switch goes back to the old one.
When rewriting from scratch is a mistake
When nobody can list everything the system does today: a system written from scratch reproduces what people remember, and the rest comes back as complaints after the switchover. Rebuilding part by part catches this before the old code is switched off. When the core calculates correctly and the trouble lies around it: slow screens, missing reports, unsupported components; replacing the surroundings is a smaller scope than a new system. We build a new system when the analysis shows that the old core cannot handle the process the company needs; that is a separate scope.
Scope
What you get
- A system map: functions, data, connections and component versions, with a decision for each: stays, replaced or updated.
- A rebuild plan in steps: the order, what works after each step and how to return to the previous state.
- Automated tests that record the system's current behaviour, run with every change.
- A record of the system's operating rules, gathered from the people who know it and readable by the next contractor.
- Rebuilt parts in daily use, with the code and documentation on the company's side.
Scope
How the work runs
- We get to know the system. We read the code and the database, talk to the person who knows the system and measure where it slows down. Outcome: a system map and a rebuild plan with a first step for your approval.
- We secure what is there. We build automated tests, set up a test environment, a copy of the system for checking changes before they reach staff, and update unsupported components. Outcome: a system on supported versions, ready for the rebuild.
- We replace one part at a time. The new part starts alongside the old one, behind the switch, with the results compared. Outcome: one function after another in the new code, with the old code switched off after your confirmation.
- We hand over the system. We hand over the code, the documentation and the way changes are made, and teach your people to run the tests. Outcome: the system is changed by your team or by a contractor under the contract; maintenance after launch is a separate scope.
Scope
Team experience
Members of the team rebuilt an infrastructure monitoring system for an internet service provider in the US market for scalability, that is, handling a heavier load. They also moved a workflow system, which routes tasks, to the Azure cloud and automated its operation for a client in the European market.
Scope
Questions the board should ask the modernisation contractor
- Which parts of the system stay, which are you replacing, and why?
- What works after the first step, and can we stop there?
- How will you check that the new part calculates the same as the old one, and who on our side will confirm it?
- How do we go back to the old version if the new part fails, and who makes that decision?
- Who talks to the person who is today the only one who knows the system, and in what form is their knowledge kept?
- Do the code, tests and documentation belong to us, and can another contractor take them over?
Where to start depends on what holds work back today, so the first step is an analysis of the system and the process, ending with a recommendation: what stays, what to replace and in what order.
Parent service
Systems and integrations
Book a meeting
Book a conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Phone: +48 455 406 404
Custom systems
A system built around your process where a ready-made product would force a change in how you work, with code and documentation that belong to your company.
See the scope
Connecting systems into one whole
One place through which the ERP, CRM, industry system and spreadsheets exchange data on their own, with a description of each exchange and a view of whether it works.
See the scope
Operational portals
A place where a customer, partner or employee submits an application, order or ticket on their own and checks its status, while the service team sees every case in one view.
See the scope
Maintenance and development
Your system after launch in the care of the team that built it: fixes, changes driven by the process and regulations, component updates and monitoring, in an order you set with us.
See the scopeHow we start
A conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Analysis under an NDA
We examine the process and the systems and hand over a recommendation with a scope of work. You know the scope, deadline and price of the analysis before it starts.
Offer
You receive the scope, team, schedule and price of the implementation. You decide whether we go ahead.
The cost of the analysis is credited towards the implementation if you order it.
Phone: +48 455 406 404 E-mail: contact@aliaxit.com