EOL audit
Find what is already out of support
We identify unsupported software, upcoming deadlines and the order in which systems should be replaced without treating the whole estate as one emergency.
Discuss your project →What the audit covers
We build an evidence-based inventory of software, versions and dependencies across workstations and servers. Each item is checked against vendor lifecycle information and, for Ukrainian operations, the official restricted-software list. We record which processes, data and integrations depend on the system, not just whether a version is old. This turns a technical inventory into a sequence of business decisions.
- Software and version inventory
- Vendor lifecycle and restriction checks
- Risk assessment by system
- Date-based replacement sequence
- Budget inputs and target-platform options
What you receive
The output is a management-ready document with systems, support dates, dependencies, consequences and replacement options. It separates immediate remediation from long migrations and identifies components that can safely remain. Every priority includes prerequisites and a validation method. The report and dependency map belong to your organisation and can be implemented internally or by any delivery partner.
Delivery format
The audit normally takes two to four weeks depending on estate size, with scope and fixed cost agreed before work begins. Access is limited to the approved minimum; much of the inventory can use exports prepared by your team. We review completeness together before handover, then leave you free to commission migration separately.
Fit before scope
Is this the right starting point?
Use these criteria for an initial orientation. The final recommendation follows a review of your context, data and constraints.
A good fit when
- Software is restricted, unsupported or creates operational risk
- Data, history and integrations must be preserved
- Process and acceptance owners are available
Resolve this first when
- Only licence procurement is required without dependency analysis
- A target was selected without validating processes and data
- No one owns reconciliation and the cutover decision
A verifiable first stage
What you can use to make the next decision
The exact scope is agreed before work begins. These are typical decision artefacts, not promised business results.
Dependency inventory
Versions, users, processes, data, integrations and critical support dates.
Replacement-wave plan
Target options, sequence, parallel operation, training and rollback path.
Acceptance rules
Reconciliations, control operations and evidence your team will use to approve the result.
Five questions · no datasets or credentials
Support calendar
Key dates for replacement planning
| Date | System or event | Status |
|---|---|---|
| 30.06.2024 | CentOS 7 end of support | Passed |
| 14.10.2025 | Windows 10 and Office 2016/2019 end of support | Passed |
| 01.2026 | Ukraine restricted-software list in effect | In effect |
| 10.2026 | Office 2021 / LTSC 2021 end of support | Upcoming |
| 13.10.2026 | Windows 10 ESU ends | Upcoming |
| 31.12.2027 | SAP ECC 6.0 EHP 6–8 support ends | Upcoming |
Sources: Microsoft end of support, Ukraine restricted-software authority, CentOS 7 lifecycle, SAP ECC lifecycle
Frequently asked questions
Frequently asked questions
Do you need direct access to our systems?
Only the minimum access agreed with you. A substantial part of the inventory can be completed from your own exports and documentation.
What if we already know the estate is old?
The audit answers what depends on each system, in what order it should be replaced and what budget inputs are required.
Must DATAMEN perform the migration afterwards?
No. The report is yours and can be implemented by your internal team or another delivery partner.
Ideas on this topic