An older Unix system nobody wants to touch
It works, the vendor options are thin, and every change carries risk nobody wants to own alone.
Enterprise engineering
Keep Linux and Unix connected to the rest of the operating picture.
Kritical works on Linux and Unix infrastructure inside mixed technology environments. We assess a platform, plan a change or investigate a problem across the operating system and the services around it, so it stops being the system nobody wants to touch.
On this page
Choose where to start.
Jump to the part that matches the problem or decision in front of you.
Use the arrows or scroll to see every card.
Three situations bring teams to this page.
A Linux estate that's grown without a consistent pattern
Different distributions, different patch cadences, different administration habits across teams.
A dependency that only shows up when something else breaks
Identity, DNS or certificate services that Linux and Windows both quietly rely on.
What you get: a platform assessment that separates cause from symptom.
Begin with the distribution or Unix platform, versions, support status and the applications it hosts. We map the service dependencies, access paths and operating procedures. An assessment distinguishes configuration issues from application constraints, capacity problems and lifecycle risks, helping you decide what to remediate and what needs a broader migration.
Why Kritical: we follow the dependencies across platforms.
Linux and Unix services often depend on shared identity, DNS, time, certificates, storage and network controls. We scope work across these interfaces, including how administrators authenticate and how services obtain the access they need. The design records both normal operation and the effects of a dependency becoming unavailable.
Identity and administrator access
Scope shared identity and how administrators authenticate.
DNS and time
Record DNS and time dependencies.
Certificates and storage
Record certificate and storage dependencies.
Network controls and failure effects
Record network controls and the effects of a dependency becoming unavailable.
Lifecycle work, made repeatable and reviewable.
Configuration, patching, automation and migration work reflects the platform's support model and the application owner's constraints. We agree the desired state, maintenance windows and verification steps before implementation. Where an older Unix environment has limited vendor options, we establish what can be tested and supported rather than assuming a modern Linux replacement is interchangeable.
How it's priced, and what happens next.
A scoped assessment or change is quoted in writing before it starts. Acceptance can cover service startup, application function, monitoring, backup and an agreed recovery scenario. Handover captures configuration changes, access arrangements, automation and known limitations, with the team responsible for ongoing operation named explicitly.
First call
We confirm the platform, the symptom or change, and what access we'd need to scope an assessment.
Get a quote
Send the systems and constraints involved and we quote the work, not just a licence.
Questions before you enquire
Which Linux distributions and Unix systems do you cover?
Tell us the exact platform, version and requirement. We confirm the available expertise and scope before committing to delivery.
Can you help with an older system?
An assessment can establish its condition, dependencies and options. Feasibility depends on access, documentation, testability and any required vendor or application support.
Can Linux integrate with our Microsoft environment?
Often, but the method depends on the application and access requirements. We can assess identity, file services, certificates and other integration points.
Is a full migration off an old Unix platform always the answer?
No. Sometimes remediation and better documentation buys years of safe runway. We say which applies before recommending either.
Can you support this alongside our VMware or on-premises estate?
Yes. Linux and Unix workloads are assessed as part of the same infrastructure and recovery picture as the rest of your virtualised environment.
Can you support open-source database or middleware components running on Linux?
Tell us the exact component, version and how it's operated today. We confirm the available expertise and whether the engagement needs a specialist beyond our own team before committing to delivery.
Do you write documentation as part of this, or just fix the immediate issue?
Handover documentation is part of the scope by default: configuration changes, access arrangements, automation and known limitations, so the fix doesn't disappear into one engineer's memory.
Let’s define the next step.
Tell us what you want to achieve, what you have today and when it matters.