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.

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 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.
- 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
| Deliverable | Form | What it is |
|---|---|---|
| Dependency map | Document and register | Every 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 records | Versioned documents | The 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 layer | Deployed system | The contract-preserving front to the legacy core through which consumers move, retired with the last one. |
| The core platform | Deployed system, source assigned | The 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 pipeline | Code and configuration | Unit, contract, integration and end-to-end tests with the pipeline that runs them, blocks failing releases and produces the audit trail. |
| Observability | Operational view | Dashboards, 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 procedures | Documents, rehearsed | How to release, roll back, restore, rotate credentials and respond to each class of incident, each one run by your team before handover. |
| Handover pack | Documents and sessions | Data dictionary, onboarding path, licence inventory and the record of your team operating the system without us. |
Where it matters
- Financial servicesSignature, where Altuon leadsCore banking migrations and integration layers where FINMA's outsourcing expectations and DORA's operational-resilience obligations apply to every change.
- HealthcareSignature, where Altuon leadsScheduling, patient-index and records platforms that must stay available through the migration and keep protected health information within HIPAA's boundaries.
- InsuranceSignature, where Altuon leadsPolicy administration and claims cores with decades of products behind them, moved one product line at a time.
- Government and public sectorCoreRegistries and case-management systems on sovereign infrastructure, with residency and audit written into the platform.
- TelecommunicationsCoreBilling and provisioning systems where every consumer is a revenue path and a cut-over cannot be a service interruption.
- Energy and utilitiesCoreMetering, billing and asset systems that run continuously and whose data outlives every application above them.
- Manufacturing and industrialSupportingOrder, planning and plant-integration platforms that connect the shop floor to the systems of record.
- Pharma and life sciencesSupportingQuality and batch-record systems where change control and audit trails are conditions of operating, not features.
Representative engagements
- Engagement blueprintReplacing a hospital network's scheduling core without stopping the clinicsA twenty-year-old scheduling system migrated site by site behind a compatibility layer, with HIPAA controls designed in and no clinic closed for a cut-over.United StatesHealthcare
- Engagement blueprintVoice agents for a Swiss private bank's client service lineA telephony-grade agent in Swiss German, French and English that answers, verifies, resolves and hands over — with recording consent handled the way FINMA expects.SwitzerlandFinancial services
Related insights
- EngineeringSeptember 9, 2026Migrating legacy core systems without stopping the businessThe big-bang cut-over is how core migrations fail. The alternative is slower, less dramatic and works: a compatibility layer, one consumer at a time, and a rollback path that is rehearsed rather than hoped for.
- BrandSeptember 9, 2026Brand identity as infrastructureAn identity that lives in a PDF is decoration. An identity that lives in tokens, templates and a governed release process is infrastructure, and it is the only kind that survives a merger, a rebrand of a subsidiary or the next chief marketing officer.
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.
