Skip to content
Software engineering, an Altuon Enterprise practice

Change the core. Never stop the business.

Core platforms, integration layers and the migration of the systems everything else depends on — carried out while the business keeps trading, one consumer at a time, with a rehearsed way back at every step. The code is half the deliverable. The tests, the observability, the documentation and the handover that leave your team independent of us are the other half.

An industrial robot and a precisely machined metal component.

What this practice is

  • A core-systems practice. We build the platforms of record — the ledger, the scheduling engine, the policy administration system, the patient index — and the integration layer that lets everything else talk to them without knowing how they are built.
  • A migration method that does not stop the business. A compatibility layer sits in front of the legacy system; consumers move to it one at a time; the new core takes over behind it, and every step has a rollback that has already been run in rehearsal, not merely written down.
  • Engineering discipline as the deliverable itself. Tests that run on every change, observability that shows what the system is doing in production, documentation written for the engineer who joins after we have gone, and a handover that ends with your team able to say no to us.
  • Built for a long service life. Well-supported technology chosen on purpose; dependencies you can still patch in fifteen years; data models that outlive the applications on top of them; and no component whose only expert works for us.

What it is not

  • A body shop. We do not supply engineers by the hour to be directed by someone else's plan. Every engagement has an architecture, an owner and gates your team signs, and the people who write the code are the people who designed it.
  • A big-bang rewrite. Nobody should switch off a system the business runs on and turn on a new one over a weekend. Where a vendor proposes that, they are proposing that you carry the risk.
  • A framework of the month. Choices are made for the life of the system, not for this year's recruitment market. Where a newer technology is the right answer, we say why in writing and what it will cost you to own.
  • Dependent on Altuon to keep running. If the source, the tests, the runbooks and the deployment pipeline would not let a competent team you hire tomorrow operate and change the system without us, the handover is not finished.

Capabilities

Core platform design and build
Systems of record for scheduling, ledgers, policy administration, patient and customer indices and order management: the data model first, the invariants written down, the services built to enforce them, and a boundary other systems can rely on.
Legacy system assessment
Reading the existing system as it is, not as its documentation describes it: the code, the database, the batch jobs, the undocumented consumers and the people who know where it bends. The output is a dependency map you can plan against.
Compatibility layer
A layer in front of the legacy core that speaks its existing contracts to every consumer while the implementation behind it changes. Consumers move one at a time; none is asked to change before the new core is ready for it.
Data migration and reconciliation
Migration of records with lineage, dual-running where the business needs it, and reconciliation that compares old and new on every record and every day until the difference is zero and stays there.
Integration layer and APIs
Versioned APIs, event streams and adapters with contracts written down, tested from both sides and enforced in the pipeline, so the teams that build on the core can move without asking us.
Rehearsed rollback
Every cut-over step has a way back that has been run in a production-like environment, timed and documented before the step is taken. Rollback is not a plan; it is a rehearsed procedure with a named owner.
Automated testing
Unit, contract, integration and end-to-end tests that run on every change and block the release when they fail; test data that mirrors production shape without production content; coverage aimed at the invariants that would hurt if broken.
Observability
Structured logs, metrics and traces designed with the operators who will read them; dashboards for the questions they actually ask at three in the morning; alerts that fire on what matters and stay silent otherwise.
Delivery pipeline and environments
Reproducible builds, environments created from code, releases that are small and frequent, and a path from a merged change to production that a person can read and an auditor can follow.
Security in the pipeline
Dependency scanning, secrets kept out of source, signed artefacts, least-privilege access, static analysis and review on every change, with findings tracked to closure and evidence kept for your auditors.
Documentation and handover
Architecture decision records, runbooks, the data dictionary and an onboarding path a new engineer can follow alone. Written during the build, not after, and tested by having someone who was not there use them.
Regulated-environment engineering
Change control, segregation of duties, audit trails and data residency built into the platform where the revised Swiss FADP, the GDPR, HIPAA, FINMA's outsourcing and operational-resilience expectations or DORA require them, so compliance is a property of the system rather than a spreadsheet beside it.
Five layers, from the data to the interfaces: what you already have, what Altuon builds and what is run togetherDataSystems of record, Legacy database, Archives and lineageCore servicesNew core platform, Domain invariants, ReconciliationCompatibility layerLegacy contracts preserved, Routing per consumer, Rehearsed rollbackAPIsVersioned APIs, Event streams, Contract testsInterfacesOperator consoles, Partner integrations, Customer channels
Altuon buildsOperated togetherThe client's

Five layers, from the data to the interfaces: what you already have, what Altuon builds and what is run together

How we deliver

Five phases, each closed by a gate your team signs. A core migration is never a single event; the new system earns its place one consumer, one data domain and one rehearsed cut-over at a time, and the old one is retired only when nothing still depends on it.

The five delivery phases and the gate that closes each01Discover02Define03Build04Prove05OperateGate
01Discover
Read the existing system as it runs: code, schema, batch jobs, interfaces and the consumers nobody listed. Interview the people who operate it. Establish what the business cannot do without, for how long, and what the regulator expects of the change.
Gate: Dependency map, business-continuity constraints and regulatory obligations approved by the technology, operations and compliance sponsors.
02Define
Design the target architecture and the compatibility layer, decide the order in which consumers move, write the data model and its invariants, set the test and observability standards, and agree the rollback procedure for every step.
Gate: Architecture, migration sequence, rollback procedures and the definition of done for tests and documentation signed; the first consumer to move named.
03Build
Build the compatibility layer and the new core behind it, the integration layer and the pipeline, with tests, observability and documentation written alongside the code. Rehearse each cut-over step in an environment shaped like production.
Gate: Test suite passing at the agreed coverage of invariants; rollback for the first cut-over rehearsed and timed; security findings closed.
04Prove
Move the first consumer onto the compatibility layer, dual-run and reconcile against the legacy system, then move the next. Each step is taken with the operators present and the rollback owner named.
Gate: Reconciliation at zero difference for the agreed period on every moved consumer; your operators have run the runbook without us; compliance sign-off on the audit trail.
05Operate
Move the remaining consumers, retire the legacy system when nothing depends on it, and hand over: your engineers ship changes through the pipeline, with our support on call until they choose not to need it.
Gate: Your team has released, rolled back and resolved an incident without Altuon involvement; the handover checklist is complete and signed.

What you receive

DeliverableFormWhat it is
Dependency mapDocument and registerEvery consumer, interface, batch job and data flow of the existing system, with the people who own each, kept current as the migration proceeds.
Target architecture and decision recordsVersioned documentsThe design of the new core and integration layer, and the record of every significant choice with the alternatives that were rejected and why.
The compatibility layerDeployed systemThe contract-preserving front to the legacy core through which consumers move, retired with the last one.
The core platformDeployed system, source assignedThe new system of record and its integration layer, running in your environment, with its source, build and infrastructure code in repositories you control.
Test suite and pipelineCode and configurationUnit, contract, integration and end-to-end tests with the pipeline that runs them, blocks failing releases and produces the audit trail.
ObservabilityOperational viewDashboards, alerts and traces designed with your operators, with the on-call guide that explains what each alert means and what to do.
Runbooks and rollback proceduresDocuments, rehearsedHow to release, roll back, restore, rotate credentials and respond to each class of incident, each one run by your team before handover.
Handover packDocuments and sessionsData dictionary, onboarding path, licence inventory and the record of your team operating the system without us.

Where it matters

Representative engagements

Related insights

Questions procurement asks

Who owns the code, and under which licences?

You do. Source written for you, infrastructure code, tests, documentation and the deployment pipeline are assigned to you on payment and live in repositories you control from the first week. Altuon retains its pre-existing methods, tooling and libraries and grants you a perpetual licence to whatever of them is embedded in your system. Third-party components are listed in a licence inventory with their terms, so nothing in your system carries an obligation you have not seen.

What is your open-source policy?

We prefer well-maintained open-source components with permissive licences and a track record of security releases, and we say so in each decision record. Copyleft licences are used only where your legal function has agreed to the obligations they carry. Every dependency is inventoried, pinned and scanned, and we contribute fixes upstream rather than forking privately, because a private fork is a component only we understand.

What documentation standard do you work to?

Documentation is part of the definition of done, not a phase at the end. Each significant decision has an architecture decision record. Each service has a readme that lets an engineer run it locally. Each operational procedure has a runbook. The data model has a dictionary. Before handover, an engineer from your team who was not on the project uses the documentation to onboard, and anything they cannot do from it is a defect we fix.

How is cut-over risk managed?

By never taking a step that cannot be reversed. The compatibility layer means consumers move individually, on their own schedule, and the legacy system keeps running until the last one has moved. Every step has a rollback procedure that has been run in a production-like environment and timed. Dual-running with daily reconciliation catches divergence before anyone downstream sees it. Cut-overs happen in the business's quietest window, with the operators present and a named person holding the decision to roll back.

What service levels and warranty apply?

Defects in work we delivered are fixed at our cost for the warranty period written into the agreement. During and after the Operate phase, support is available under a retainer with response and resolution targets set by severity, written into the contract, and reported against so you can see they were met. We do not offer service levels for infrastructure you operate, but we design and document the system so your own targets are achievable, and we say in writing where they are not.

What happens at exit?

The system keeps running without us, because that was a gate. On exit you already hold the source, the pipeline, the documentation and the operational record. We provide a transition period at the agreed rate, a walkthrough for any successor you appoint, and the return or deletion of any data we held, with confirmation in writing. Key people on the engagement are named in advance and paired, so no knowledge leaves with a single person.

How is security handled in the pipeline?

Every change is reviewed by a second engineer and passes static analysis, dependency scanning and secret scanning before it can merge. Build artefacts are signed and deployed from the pipeline, never from a laptop. Access follows least privilege, with audit logs kept. Findings are tracked to closure with evidence your auditors can read, and the controls are mapped to the frameworks that apply to you: the revised Swiss FADP, the GDPR, Jordan's Personal Data Protection Law, HIPAA, FINMA's expectations on outsourcing and operational resilience, and DORA where you are an EU financial entity.

Show us the system nobody wants to touch.

The Discover phase begins with the code as it runs and the people who keep it running, and ends with a dependency map and a migration sequence you can defend to your board. Request a proposal, or book an executive briefing for the people who will sign the first cut-over.