Custom software & system modernization
When your core system runs the business, a rewrite is a gamble you cannot take. We modernize it piece by piece, in production, with no overnight switch that could take the whole company down.
- Strangler pattern
- Routing layer
- Dual-run data migration
- Legacy integration
- Zero big-bang cutover
- Proven tech stack
This is for established companies whose software has become the business — the system that books the orders, moves the money, or runs the floor. It works, mostly, but it is years of decisions deep, the people who built it have moved on, and every change feels risky. A clean rewrite sounds tempting until you price the two years of running both worlds at once, and a failed cutover is the kind of event that reaches the board.
We take the opposite bet. Instead of a single switch from old to new, we modernize the system in place, one capability at a time, with each replacement running in production next to the part it replaces until it has earned the right to take over. The business keeps running the whole way through. There is no weekend where everything changes and everyone holds their breath.
The people who scope this work are the people who ship it — one senior team, the same architecture review, from the first read of your code to the last legacy path switched off. You own the result outright, with no dependency on us to keep it alive.
Toto je pre zavedené firmy, ktorých softvér sa stal samotným biznisom — systém, ktorý prijíma objednávky, posúva peniaze alebo riadi prevádzku. Väčšinou funguje, no je navrstvený z rokov rozhodnutí, ľudia, ktorí ho stavali, už dávno odišli a každá zmena pôsobí rizikovo. Prepísať ho nanovo znie lákavo, kým si nespočítate dva roky súbežnej prevádzky dvoch svetov — a neúspešné prepnutie je udalosť, ktorá sa dostane až pred predstavenstvo.
My stavíme na opak. Namiesto jediného prepnutia zo starého na nové modernizujeme systém priamo na mieste, jednu schopnosť po druhej, pričom každá náhrada beží v prevádzke vedľa časti, ktorú nahrádza, dokým nedokáže, že jej úlohu zvládne prevziať. Biznis beží po celý čas. Niet víkendu, počas ktorého sa všetko zmení a všetci zatajujú dych.
Ľudia, ktorí prácu navrhnú, sú tí, čo ju aj dodajú — jeden senior tím, rovnaký architektonický dohľad, od prvého prečítania vášho kódu až po vypnutie poslednej legacy cesty. Výsledok vlastníte úplne, bez závislosti na nás, aby ste ho udržali nažive.
How we modernize without stopping the business
Discovery and audit
We spend the first couple of weeks reading the code and tracing the data, not just interviewing people — because the real system is in what actually runs, and the gap between how a system is described and how it behaves is where the risk lives. We follow the critical paths end to end, find the undocumented jobs and the integrations nobody mentions, and watch where the data truly flows.
You come out of it with a dependency map and a risk register your board can act on — what is load-bearing, what is fragile, what would cost you most if it failed — plus a written, costed plan for the order we would tackle it in. It is a short fixed-fee audit, and it stands on its own even if you take it to someone else.
Prvé zhruba dva týždne trávime čítaním kódu a sledovaním dát, nie len rozhovormi s ľuďmi — pretože skutočný systém je v tom, čo reálne beží, a priepasť medzi tým, ako je systém opísaný a ako sa správa, je miesto, kde sa skrýva riziko. Prechádzame kritické cesty od začiatku do konca, nachádzame nezdokumentované úlohy a integrácie, ktoré nikto nespomenul, a sledujeme, kadiaľ dáta skutočne tečú.
Odchádzate s mapou závislostí a registrom rizík, s ktorými vaše predstavenstvo vie pracovať — čo je nosné, čo je krehké a čo by vás stálo najviac, keby to zlyhalo — a s písomným a naceneným plánom poradia, v akom by sme to riešili. Je to krátky audit s pevnou cenou a obstojí sám osebe, aj keby ste s ním šli inam.
OutputA dependency map, a prioritised risk register, and a costed modernization plan
Architecture and sequencing
We design the target shape and, just as importantly, the order of operations to reach it. A routing layer goes in front of the legacy system so traffic can be sent to either the old path or a new one per capability — this is what makes incremental replacement possible without the business noticing a seam.
Sequencing is driven by business risk, not by which parts are the most satisfying to rebuild. We start where a failure would hurt most or where the old code blocks everything else, and we leave the quiet, stable corners for last — sometimes forever, if replacing them buys nothing. Every significant decision is written down as a short record of what we chose and why.
Navrhujeme cieľový tvar a — rovnako dôležité — poradie krokov, ktorými sa k nemu dostaneme. Pred legacy systém vložíme smerovaciu vrstvu, aby bolo možné posielať prevádzku buď na starú, alebo na novú cestu podľa jednotlivých schopností — práve to umožňuje postupnú náhradu bez toho, aby biznis zbadal spoj.
Poradie určuje riziko pre biznis, nie to, ktoré časti sa prepisujú najpríjemnejšie. Začíname tam, kde by zlyhanie bolelo najviac alebo kde starý kód blokuje všetko ostatné, a tiché, stabilné kúty necháme nakoniec — niekedy navždy, ak ich náhrada neprinesie nič. Každé významné rozhodnutie zapisujeme ako krátky záznam o tom, čo sme zvolili a prečo.
OutputA target architecture, a routing layer plan, and a risk-ordered sequence with decision records
Build in slices
We work in two-week iterations, each ending in working software demoed to the people who use it. A slice is one capability — a report, a workflow, an API — rebuilt, deployed behind the routing layer, and run live alongside the old version so the two can be compared on real traffic before anything is trusted to the new path.
Nothing is a big reveal at the end. You see each piece land, in production, while the system you depend on keeps serving everyone exactly as before. If a slice is not right, we have changed one capability, not bet the company.
Pracujeme v dvojtýždňových iteráciách, z ktorých každá končí funkčným softvérom predvedeným ľuďom, ktorí ho používajú. Časť je jedna schopnosť — report, pracovný postup, API — prestavaná, nasadená za smerovaciu vrstvu a bežiaca naživo popri starej verzii, aby sa obe dali porovnať na reálnej prevádzke skôr, než sa čokoľvek zverí novej ceste.
Nič nie je veľké odhalenie na konci. Každý diel vidíte pristáť v prevádzke, kým systém, na ktorom stojíte, obsluhuje všetkých presne ako predtým. Ak časť nie je v poriadku, zmenili sme jednu schopnosť, nie stávku o celú firmu.
OutputWorking releases every two weeks, each one capability live in production
Migrate and integrate
Moving the data is the hard part, and we treat it that way. For each slice we run the old and new stores in parallel, reconcile them continuously, and only cut a capability over once the numbers match — then keep the old path warm so we can fall back in minutes if something surfaces. Every migration step is reversible until we delete the old path, which we do only once it has proven itself.
Where you have systems we cannot or should not replace, we integrate around them — the payroll engine, the regulator's interface, the warehouse controller — so the modern parts and the legacy core cooperate cleanly instead of being forced into one rewrite.
Presun dát je tá ťažká časť a tak k nemu aj pristupujeme. Pre každú časť necháme staré a nové úložisko bežať súbežne, priebežne ich zosúlaďujeme a schopnosť prepneme až vtedy, keď sa čísla zhodujú — a potom necháme starú cestu v pohotovosti, aby sme sa k nej vedeli vrátiť v priebehu minút, ak sa niečo vynorí. Každý krok migrácie je vratný, až kým starú cestu nezmažeme, čo urobíme, len keď sa osvedčí.
Tam, kde máte systémy, ktoré nemôžeme alebo nemáme nahrádzať, integrujeme okolo nich — mzdový engine, rozhranie regulátora, riadenie skladu — tak, aby moderné časti a legacy jadro spolupracovali čisto namiesto toho, aby boli natlačené do jedného prepisu.
OutputData migrated slice by slice with dual-run and reconciliation, integrations in place, each step reversible
Cutover and harden
Cutover happens in slices, never all at once, and each one is rehearsed. We load-test the new paths, run security and failure drills, and confirm regulatory obligations — GDPR, and sector rules where they apply — before the old code is switched off. Only after a capability has carried full production traffic cleanly do we delete its legacy path for good.
You get a readiness report for each cutover: what was tested, what the fallback is, and the evidence that the new path matches the old one. The result is fewer moving parts than you started with, not more.
Prepnutie prebieha po častiach, nikdy naraz, a každé je nacvičené. Nové cesty záťažovo testujeme, robíme bezpečnostné skúšky a skúšky zlyhania a potvrdzujeme regulačné povinnosti — GDPR a sektorové pravidlá tam, kde platia — skôr, než sa starý kód vypne. Legacy cestu konkrétnej schopnosti zmažeme natrvalo až potom, čo bez problémov unesie plnú produkčnú prevádzku.
Ku každému prepnutiu dostanete správu o pripravenosti: čo sa testovalo, aká je záložná cesta a dôkaz, že nová cesta sa zhoduje so starou. Výsledkom je menej pohyblivých častí, než ste mali na začiatku, nie viac.
OutputLoad, security and failure testing, a readiness report per cutover, and legacy paths retired
Handover
Everything is built to be owned by you, not rented from us. We hand over documented code, the decision records, runbooks for the things that can go wrong, and training for the people who will carry it. We stay for a defined transition and then step back on purpose.
We choose boring, proven technology from the start precisely so that this moment works — stacks you can hire for and that will still be supported in a decade, with every choice written down. There is no proprietary ETEREO layer you would have to keep paying for.
Všetko je postavené tak, aby ste to vlastnili vy, nie aby ste si to od nás prenajímali. Odovzdávame zdokumentovaný kód, záznamy rozhodnutí, príručky pre prípady, keď sa niečo pokazí, a zaškolenie ľudí, ktorí to budú niesť. Zostaneme na vymedzený čas prechodu a potom zámerne ustúpime.
Nudnú, overenú technológiu volíme od začiatku práve preto, aby tento moment vyšiel — technológie, na ktoré viete nabrať ľudí a ktoré budú podporované aj o desať rokov, s každým rozhodnutím zapísaným. Niet žiadnej proprietárnej vrstvy ETEREO, za ktorú by ste museli ďalej platiť.
OutputDocumentation, runbooks, training, and full ownership of the code and the know-how
What you walk away with
- A dependency map and risk register your board can act on
- A costed, risk-ordered modernization plan from the fixed-fee audit
- A routing layer that lets old and new run side by side
- Decision records explaining every significant choice
- Data migrated in reversible slices, with reconciliation evidence
- Clean integrations with the systems you keep
- Documented code, runbooks, training, and full ownership
How we think about modernization
The honest case against a big-bang rewrite is simple: it asks you to run two systems in parallel for years, reproduce behaviour nobody fully remembers, and then switch everything on one date — and the day you learn whether it worked is the worst possible day to find out. Most rewrites that start this way either never ship or ship late and wounded.
The incremental path we use is sometimes called the strangler approach: you put a routing layer in front of the old system and grow the new one around it, replacing a capability at a time, until the legacy core has been quietly surrounded and can be removed. The business never stops. Risk is paid down in small, reversible increments instead of saved up for one enormous bet.
We choose technology for longevity and hiring, not novelty — the kind of stack a new engineer already knows and that will still be maintained long after we are gone. Every decision is documented, because a modernization you cannot understand later is just a different legacy system.
Čestný argument proti veľkému prepísaniu nanovo je jednoduchý: žiada od vás, aby ste roky prevádzkovali dva systémy súbežne, zreprodukovali správanie, ktoré si už nikto úplne nepamätá, a potom všetko zapli v jeden dátum — pričom deň, keď sa dozviete, či to fungovalo, je ten najhorší možný deň na to, aby ste to zistili. Väčšina prepisov, ktoré takto začnú, buď nikdy nedoputuje do prevádzky, alebo doputuje neskoro a doráňaná.
Postupná cesta, ktorú používame, sa niekedy nazýva strangler prístup: pred starý systém vložíte smerovaciu vrstvu a nový systém okolo neho necháte rásť, nahrádzajúc jednu schopnosť po druhej, dokým legacy jadro ticho neobkolesíte a nedá sa odstrániť. Biznis sa nikdy nezastaví. Riziko sa spláca v malých, vratných krokoch namiesto toho, aby sa šetrilo na jednu obrovskú stávku.
Technológiu volíme pre dlhovekosť a nábor, nie pre novosť — taký stack, ktorý nový inžinier už pozná a ktorý bude udržiavaný dávno potom, čo my odídeme. Každé rozhodnutie je zdokumentované, pretože modernizácia, ktorej neskôr nerozumiete, je len iný legacy systém.
Common questions
Why not just rewrite it from scratch?
Because a rewrite asks you to reproduce years of accumulated behaviour, run two systems at once for a long time, and then bet the business on a single cutover date. For a load-bearing system, that risk is rarely worth it. Replacing one capability at a time keeps the business running and lets you stop, or change course, at any point — something a big-bang rewrite never allows.
Pretože prepísanie od vás žiada zreprodukovať roky nahromadeného správania, prevádzkovať dlho dva systémy naraz a potom staviť biznis na jediný dátum prepnutia. Pri nosnom systéme sa to riziko málokedy oplatí. Nahradenie jednej schopnosti po druhej udrží biznis v chode a umožní vám kedykoľvek sa zastaviť alebo zmeniť kurz — čo veľké prepísanie nikdy nedovolí.
How do you modernize without downtime?
A routing layer sits in front of the legacy system and sends each request to the old path or a new one. We build a capability, run it in production next to the version it replaces, compare them on real traffic, and only then route users to it. Because every slice is reversible until the old path is deleted, there is no weekend cutover and no moment where the whole system changes at once.
Pred legacy systémom sedí smerovacia vrstva a každú požiadavku posiela buď na starú, alebo na novú cestu. Postavíme schopnosť, spustíme ju v prevádzke vedľa verzie, ktorú nahrádza, porovnáme ich na reálnej prevádzke a až potom na ňu smerujeme používateľov. Keďže každá časť je vratná, až kým sa stará cesta nezmaže, niet víkendového prepnutia ani okamihu, keď sa celý systém zmení naraz.
What about our data — isn't migration the scary part?
It is the hard part, so we treat it as the main event rather than a final step. For each slice we run the old and new data stores in parallel, reconcile them continuously, and cut over only when the numbers agree — keeping the old path warm so we can fall back in minutes. We migrate in slices, not in one overnight dump, so a problem is contained to one capability instead of the whole dataset.
Je to tá ťažká časť, preto ju berieme ako hlavnú udalosť, nie ako posledný krok. Pre každú časť necháme staré a nové úložisko bežať súbežne, priebežne ich zosúlaďujeme a prepneme až vtedy, keď sa čísla zhodujú — pričom starú cestu držíme v pohotovosti, aby sme sa k nej vedeli vrátiť v priebehu minút. Migrujeme po častiach, nie jedným nočným presunom, takže problém sa udrží v jednej schopnosti namiesto celého súboru dát.
Will we be locked in to ETEREO afterwards?
No, and we design against it deliberately. You own the code, and we hand over documentation, decision records, runbooks and training so your own team can run and extend it. We build on boring, proven, widely known technology precisely so you can hire for it, and there is no proprietary layer of ours that you would have to keep paying to license.
Nie, a zámerne to tak navrhujeme. Kód vlastníte vy a odovzdávame dokumentáciu, záznamy rozhodnutí, príručky a zaškolenie, aby ho váš vlastný tím vedel prevádzkovať a rozširovať. Staviame na nudnej, overenej a široko známej technológii práve preto, aby ste naň vedeli nabrať ľudí, a niet žiadnej našej proprietárnej vrstvy, za licenciu ktorej by ste museli ďalej platiť.
Can you work with a system you cannot fully replace?
Yes — that is the normal case. Some parts are too regulated, too specialised, or simply not worth replacing. We integrate around them cleanly, letting the modern capabilities and the legacy core cooperate, and we are honest when the right answer is to leave something as it is rather than spend your budget touching a stable corner that works.
Áno — to je bežný prípad. Niektoré časti sú príliš regulované, príliš špecializované alebo jednoducho nestojí za to ich nahrádzať. Integrujeme okolo nich čisto, necháme moderné schopnosti a legacy jadro spolupracovať, a sme úprimní, keď je správnou odpoveďou nechať niečo tak, ako to je, namiesto toho, aby sme vám minuli rozpočet na stabilný kút, ktorý funguje.
Is your core system too important to rewrite?
Start with a short, fixed-fee audit — we read the code and the data and give your board a dependency map, a risk register, and a costed plan for modernizing without stopping the business.
Book a modernization audit