Restricted software migration
Migration from KOMPAS-3D, T-FLEX and Pilot
We plan the replacement of CAD, PDM and PLM systems while preserving required data, integrations and transition control.
Discuss your project →What the migration covers
We begin with an inventory of products, versions, servers, workstations, integrations and process owners. Inclusion in the official list is a reason to review the environment, but it does not automatically determine the target. Selection follows functional, security, operational and budget requirements.
- native files, drawings and 3D models
- bills of materials, attributes and classifiers
- versions, relationships and change history
- approval workflows, templates and integrations
How the target is selected
We create a vendor-neutral requirements matrix covering critical functions, formats, APIs, hosting, support, export and team capability. Alternatives are tested on a control set before bulk migration. No single product is presented as a universal replacement for every organisation.
Validation and handover
Before selecting the target, we test a control set for geometry, layers, fonts, bills of materials and document links. Part of the archive may remain in a long-term readable format.
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
Answer first
How should you choose a replacement?
When replacing KOMPAS-3D, T-FLEX, Pilot or related PDM/PLM systems, preserving files alone is insufficient: product structures, versions, attributes and relationships must survive. Alternatives are evaluated on real models and approval workflows.
Model fidelity
Geometry, drawings, bills of materials, libraries and dependencies open without critical loss.
Data management
Versions, states, attributes, permissions, approvals and product structures are retained.
Engineering workflow
ERP, CAM, simulation tools and engineering workstations remain integrated.
Evidence of completion: Acceptance uses a representative model sample, a quantified difference report and an end-to-end engineering change test.
Support calendar
Examples from Ukraine's official list
| Product or group | Status |
|---|---|
| КОМПАС-3D | Listed |
| Pilot-BIM / Pilot-ECM | Listed |
| T-FLEX PLM | Listed |
| T-FLEX DOCs / PDM | Listed |
Sources: Ukraine's State Service of Special Communications - open list, page dated 5 August 2026
Frequently asked questions
Frequently asked questions
Must everything be replaced at once?
No. Inventory defines waves based on criticality, dependencies, export feasibility and change windows.
Does listing mean a fine for every private business?
This page makes no such conclusion. Scope and obligations depend on the organisation and applicable rules. Seek qualified legal advice for a legal assessment.
How is migration completeness demonstrated?
Control samples, quantitative reconciliation, critical scenarios and an acceptance record are agreed before migration.
Ideas on this topic