Where we step into CANIAS projects
We do not resell CANIAS ERP; we work on your installation. Licensing, release policy and the product roadmap are the vendor's responsibility. Our job is to solve the processes the standard does not cover, using the platform's own methods, and to do it without breaking version upgrades.
This page does not explain what the product is. For the layer architecture, module groups and evaluation criteria, see what is CANIAS ERP.
What we take on in your CANIAS installation
Module implementation and go-live
We map your processes onto what the standard covers and list what it does not in a fit-gap register. Module go-live, master data design, opening balances and data migration are planned from that register. Which process is solved by configuration and which by development is stated separately in the scope document.
Development and customisation with TROIA
TROIA is CANIAS's own development platform, with its own IDE, compiler and interpreter. We write screen, report, workflow and process customisations on that platform. The code lives inside the application; we do not stand up a side system that bypasses the ERP.
Integration
We build the links to banks, e-invoicing, POS, e-commerce, B2B, WMS, production systems and third-party services. Our baseline is that a retried request must not create a duplicate record and that every flow must be observable; the detail is on the API and system integration page.
Version upgrades and maintenance
Upgrading an existing installation, reviewing accumulated customisations and ongoing support. Before an upgrade we establish which customisations are still in use and which are dead code; a customisation that does not have to be carried forward makes the upgrade cheaper.
Writing customisation without breaking the upgrade
CANIAS provides a structure that lets a customisation be written without editing the standard object directly: a customer-owned class takes the place of the standard class. The discipline is this — when standard behaviour must change, it is handled in the customer layer rather than by editing the standard source.
There is a price, and we say it up front: every customisation is customisation debt. The upgrade is where that debt is settled. So we do not turn every request into development; if the standard offers an acceptable route, we propose that first.
How a CANIAS project runs
- Current-state analysis. Which release the installation is on, which modules are genuinely used, and an inventory of existing customisations.
- Fit-gap. The processes the standard covers and those it does not are listed separately.
- Scope and method. For each gap — configuration, TROIA development or integration — decided in writing.
- Development and testing. Customisations are written in a test environment; the acceptance criteria are the items in the scope document.
- Go-live. Data migration, parallel running and a user training plan.
- Maintenance. An upgrade calendar and keeping the customisation inventory current.
What this page does not claim
We publish no unmeasured success rate, average project duration or customer count. CANIAS module coverage and licence rights depend on your own contract; nothing on this page replaces the vendor's licence terms. We recommend verifying the product's current capabilities in the vendor's own documentation.
Frequently asked questions
Are you a CANIAS partner?
No. We hold no formal partnership on the CANIAS side; we provide independent consulting. Your counterpart for licensing and product support is the vendor.
We already run CANIAS — can you work without starting over?
Yes; a substantial part of our work is on installations that are already live. We start by taking an inventory of the existing customisations.
Who owns the TROIA development?
The code we write stays in your installation and its source is yours. The scope document records the rationale for each customisation and the standard object it affects; if you continue with another team, the handover runs through that document.
Will our customisations be lost in a version upgrade?
If a customisation was written in the customer layer, an upgrade does not delete it outright — but it can conflict with changed standard behaviour. That is why a customisation inventory is produced before the upgrade and each item is assessed individually.