ERPNext or iDempiere: when each one fits a manufacturer or distributor
For a mid-sized manufacturer or distributor with these two platforms on the shortlist, the choice turns mainly on two things: the skills your team already has or can hire for, and where you want to host the system. ERPNext is a Python and JavaScript stack on the Frappe Framework with MariaDB, while iDempiere is Java built on OSGi plugins, the ZK web framework and PostgreSQL or Oracle. Both are GPL licensed and neither has a paid edition of the core software, so this is not a decision about license tiers or feature locks. Choose ERPNext when your IT staff or integrator is strong in Python and you want a broad suite that covers accounting, inventory, manufacturing, assets and projects in one Frappe-based codebase, with the option of Frappe Cloud if you prefer managed hosting over your own servers. Choose iDempiere when your team works in Java, when you need an OSGi plugin model for customizations, or when an LTS release line and an accounting core described by its community as enterprise quality fit your governance needs. Confirm module coverage for your own bill of materials, routing and distribution workflows against both before you rely on either. The rest of this page tests those factors in order: module coverage for manufacturing and distribution, accounting depth, how customizations are built and maintained, release and support windows, hosting options, and the in-house skills each platform demands over time. Use those sections to score the two against your own roles, data volumes and hosting constraints.
Which scenario favors ERPNext and which favors iDempiere
This table maps common buyer scenarios for a mid-sized manufacturer or distributor to the platform that fits better, with the condition that would reverse the choice. Read each row against your own team skills, hosting rules and database standards before shortlisting either platform.
| Scenario | Better fit and reason | When the other platform is the better choice |
|---|---|---|
| Existing Python developers in-house | ERPNext. Its Frappe Framework is Python and JavaScript, so customization skills already on staff carry over. | iDempiere, if the team later needs Java plugins on OSGi and has no Python capacity to maintain custom code. |
| Existing Java and PostgreSQL staff | iDempiere. It is built with Java, ZK, OSGi and Maven and runs on PostgreSQL, matching existing skills. | ERPNext, if you are willing to retrain staff on Python and MariaDB, which the Frappe stack requires. |
| Need for managed hosting | ERPNext. Frappe Cloud is the vendor's managed hosting for ERPNext, handling installation, upgrades, monitoring and support. Confirm current plans and terms directly with Frappe. | iDempiere, if you prefer a hosting provider or your own infrastructure team. Confirm what managed options exist for iDempiere with its community or service providers. |
| Need for Oracle as the database | iDempiere. It runs on PostgreSQL or Oracle, while the Frappe stack in the supplied facts is built on MariaDB. | ERPNext, if Oracle is not a requirement. Confirm whether Frappe supports any other database before assuming MariaDB is the only option. |
| Heavy manufacturing bill of materials | Confirm in both demos. ERPNext covers manufacturing among its listed modules, so test multi-level bills of materials and work orders against your real data. | iDempiere, if your Tier II ERP/CRM/SCM needs center on enterprise-grade accounting and you need to verify its manufacturing depth on a pilot dataset. |
| Need for a long-term support release | iDempiere. Version 13 Orion is announced as a long-term support release. Confirm its support end date with the iDempiere community before committing. | ERPNext, if rolling supported releases fit your upgrade plan. ERPNext v16 is supported until the end of 2029 and v15 until the end of 2027, according to Frappe's supported versions page. |
| Large initial data migration | ERPNext. Its Data Import tool loads CSV, Excel and Google Sheets with child table support, though the documentation advises importing only a few thousand records at a time. | iDempiere, if your migration relies on existing Compiere or ADempiere data structures, which should be validated by an implementation partner. |
How each platform is built and what that means for operations
ERPNext and iDempiere solve the same business problems with very different runtime stacks. The choice of language, database, application server and release cadence decides which engineers you need on call and how upgrades reach your servers. Each card below names one component and the operational consequence the operations team should weigh.
Frappe Framework on Python and JavaScript
ERPNext runs on the Frappe Framework, a full-stack Python and JavaScript framework under the MIT license. Business logic, document models and custom code are mostly Python, while the browser client is JavaScript. Your team needs Python and JavaScript skills to troubleshoot, and the framework ships with its own bench command line tool that operations staff must learn. Ask the vendor how many custom apps your team would maintain on top of the core.
MariaDB, Redis or Valkey, and Node.js
Frappe Framework v16 requires MariaDB 11.8, Redis or Valkey 6 or later, and Node.js 24. A database engine, a cache and queue service, and a JavaScript runtime all need patching and version tracking. The MariaDB and Node.js requirements are the ones most likely to force a server rebuild before a major upgrade, so confirm your distribution packages can supply them or plan for a container image route.
Workers, scheduler and Socket.io
A production ERPNext deployment runs background workers, a scheduler, a Socket.io real-time service and Nginx in front of the application, as the frappe_docker project lays out. Each process is a separate thing to monitor, restart and scale. Stuck queues or a stopped scheduler can halt month-end jobs without an obvious user-facing error, so ask the vendor which health checks and alerts they would configure for each process.
Java runtime, ZK and application server
iDempiere is built with Java, the ZK web framework and Maven, and it runs as a Java application server process. Operations teams need a supported Java runtime, a process manager, log handling and JVM memory tuning under their own standards. Confirm with the iDempiere project which Java version, application server and build tooling the current release expects, because this document does not set those requirements.
OSGi bundle lifecycle
iDempiere extends its core through a plugin system powered by OSGi. Each plugin is a bundle that can be installed, started, stopped, updated or removed while the platform runs, and bundles can depend on one another. This makes patching a plugin a lifecycle task, not only a file copy. Ask how bundle version conflicts are detected during upgrades and which team owns plugin compatibility testing after each release.
PostgreSQL or Oracle database choice
iDempiere runs on PostgreSQL or Oracle, so the database choice changes your licensing exposure, DBA skills and backup tooling. Choosing Oracle adds a commercial database contract to the platform cost, while PostgreSQL keeps the stack open source. Ask the iDempiere project and your database vendor to confirm which database versions each current iDempiere release supports before you commit to a host image.
Side-by-side capabilities for ERPNext and iDempiere
This table compares ERPNext and iDempiere on license, stack, extension model, data import, identity integration, release windows and hosting. Where the supplied research has no iDempiere value, the cell tells you what to confirm with the community or your own test environment. Read it as a checklist of questions to settle before a shortlist turns into a contract.
| Capability | ERPNext | iDempiere |
|---|---|---|
| License | GPL-3.0 for ERPNext, built on the Frappe Framework licensed under MIT | GPL-2.0 per the repository README and LICENSE |
| Core scope | Accounting, order and inventory management, manufacturing, asset management and projects in one suite | ERP, CRM and supply chain management, with an enterprise-quality accounting system; confirm module depth for manufacturing and projects |
| Application stack | Python and JavaScript on the Frappe Framework | Java with the ZK web framework, OSGi and Maven |
| Database options | MariaDB, with Redis or Valkey for Frappe v16 | PostgreSQL or Oracle; confirm which Oracle versions your team would support |
| Plugin or extension model | Frappe apps installed on a bench; Server Scripts for in-app logic | Modular plugin system powered by OSGi; confirm how plugins are versioned and upgraded |
| Customization tools | Server Scripts in Python, disabled by default from v15 and enabled with server_script_enabled; not available on Frappe Cloud public shared benches | Java development with OSGi plugins; confirm the supported development workflow with the community |
| Data import | Data Import tool for CSV, Excel or public Google Sheets with child table rows; documentation advises a few thousand records at a time | Confirm the bulk import tooling and limits for your data volumes |
| Identity integration | LDAP integration and Social Login Key documentation | Confirm LDAP, SSO and OAuth options with the project or your integrator |
| Release and support windows | v15 line supported to the end of 2027 and v16 to the end of 2029, with frequent minor releases | Release-9 through release-13 branches kept; release 13 "Orion" is an LTS release announced March 12, 2026 |
| Hosting options | Self-hosted with Docker, bench or Frappe Cloud; Frappe Cloud shared and dedicated server plans | Self-hosted on your infrastructure; confirm managed hosting providers and public test sites |
How each platform is customized and how users sign in
Choose ERPNext's customization model when your team writes Python and wants changes to stay inside the Frappe framework. The lightest option is a Server Script, which runs Python on document events such as saving or submitting a record, or exposes an API endpoint. Since version 15, Server Scripts are disabled by default and must be turned on with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so a team that plans to use them needs a bench where it controls that setting. Larger changes belong in a custom app, which keeps code in version control, separate from core, and easier to test on each upgrade.
iDempiere extends behavior through its OSGi plugin system, where functionality is packaged as bundles built with Maven and loaded into the Java application. A plugin change alters code that runs inside the live ERP, so each change needs a rebuild, deployment to a test environment, and regression testing against every iDempiere release line you intend to follow. This approach fits best when your team already has Java and OSGi skills, or a partner who will maintain them for the life of the system, and when the requirements are deep enough to justify that upkeep. Ask any implementer how plugins are versioned against the release branch in use, such as release-13, and who owns the upgrade test cycle.
Sign-in is where the documented depth differs most. ERPNext documents LDAP integration for directory-based accounts and Social Login Key for external identity providers, so a team with an existing directory can plan user mapping before go-live. Confirm how group membership maps to ERPNext roles and what happens to deactivated accounts in your own setup. For iDempiere, confirm with the project and in your own environment which SSO protocols are supported, whether directory integration ships with the product or needs a plugin, and how that integration is maintained through upgrades. Treat identity integration as a test item on both platforms, not as a final step.
What is free, what is paid and what support costs for each platform
ERPNext is licensed under GPL-3.0 and built on the Frappe Framework, which is licensed under MIT. Using the software carries no license fee, and the ERPNext pricing page states that self-hosting is free. Your spend moves to infrastructure, implementation and any support contract, and those costs depend on how you run the system.
- Self-hosting: Software is free, but you pay for servers, storage, backups, monitoring and the staff or partner who operates them.
- Frappe Cloud shared hosting: The pricing page lists shared site hosting from 5 US dollars per month and shared servers from 20 US dollars per month.
- Frappe Cloud dedicated servers: The same page lists dedicated servers from 125 US dollars per month. Frappe Cloud also handles installation, upgrades, monitoring and support.
- Warranty coverage: Frappe's supported versions policy says you must run a listed version and hold a matching Frappe Cloud support plan to receive warranty coverage from Frappe. The sources reviewed for this page do not give support plan prices, so ask Frappe for current figures.
- Implementation: The pricing page says implementation is available through certified partners, so the largest one-time cost usually sits outside the software license.
Before you compare totals, confirm which Frappe version your plan covers and whether you need a Frappe Cloud support plan to get the warranty you require.
The iDempiere repository is licensed under GPL-2.0, so the core product carries no license fee. The project is community-driven, with development by SMEs, implementors and end users. This page does not identify a paid edition of iDempiere, so the cost question becomes who provides support, on what terms and at what price.
- License: The repository README and LICENSE file state GPL-2.0. Confirm with counsel how that license applies to any custom plugins you plan to distribute.
- Paid edition: This page does not identify a commercial edition or vendor subscription. Ask the project and your implementers in writing what commercial support they offer.
- Community support: The Google Group forum and Mattermost chat are useful for questions, but they are not a contract and carry no response commitment unless an implementer provides one.
- Release and LTS: iDempiere 13 "Orion" is a long-term support release, announced on the project website on March 12, 2026. Confirm the support window for that release with the project and your implementer.
- Implementation cost: Because the software is free, most of the spend is the implementer's fee and the Java, PostgreSQL or Oracle skills your team needs to run the system.
Ask any implementer to state in writing whether support is billed per incident, per year or as a retainer, and which iDempiere version the quote covers. Start with the iDempiere website for the current project information.
Whatever platform you choose, a quote should separate one-time work from recurring spend. The same structure applies to ERPNext and iDempiere, and DeployOpen does not publish a price list, so each quote follows from a written scope that both sides agree before work starts.
- One-time costs: Discovery, data migration, customization, integration with identity and reporting systems, and acceptance testing.
- Recurring costs: Hosting, backups, monitoring, upgrades, security patching and any support contract.
- Cost drivers: The number of sites, custom apps or plugins, data volume and integrations all raise both one-time and recurring spend.
- Terms to request: Named deliverables, the exact version covered, support hours, response targets written into the contract and the party that holds the warranty.
- Exit costs: Ask what export formats, data access and upgrade paths exist if you move to another platform later.
Compare two quotes only after both list the same version, the same scope and the same recurring items.
What drives the running cost of ERPNext and iDempiere
Neither platform carries a license fee for self-hosting, so the running cost comes from who operates the stack. For ERPNext, the infrastructure choice is between your own servers and Frappe Cloud, where the pricing page lists shared site hosting from 5 US dollars per month, shared servers from 20 US dollars per month and dedicated servers from 125 US dollars per month. Self-hosting avoids those plan fees but moves the cost to your servers and to staff who run MariaDB, Redis or Valkey, background workers and the scheduler. iDempiere runs on your infrastructure with PostgreSQL or Oracle, so the team needs Java, ZK, OSGi and Maven skills to patch, rebuild and troubleshoot it. Confirm whether those skills already exist in house, because hiring or contracting them is a recurring line that the license terms do not reveal.
Implementation, data migration and custom development are one-time costs, while hosting, support subscriptions, upgrades and staff time recur. Migration effort depends on volume: the ERPNext Data Import documentation advises importing only a few thousand records at a time, so large histories need staged loads and reconciliation. Customization often drives recurring cost more than the initial build. From version 15, Server Scripts are disabled by default and must be enabled with server_script_enabled, so business logic usually lives in custom apps that must be retested on every upgrade. iDempiere places custom behavior in OSGi plugins with the same retesting burden. The number of sites, custom apps or plugins and the release line you choose all multiply upgrade testing. ERPNext v14 reached end of life on January 31, 2026, so a team still on that line faces a forced move.
How to move data and customizations from one platform to the other
This sequence turns a move between ERPNext and iDempiere into a tested, reversible cutover. Each step produces a documented input for the next, so the team knows what moves as data, what is rebuilt, and when the new system is ready to take over.
Inventory data, customizations and integrations
Before any data moves, the project lead and the finance and operations owners list every master dataset, open transaction type, custom report, plugin or app, server-side script, scheduled job, print format and integration with banks, payroll, e-commerce or shipping systems. Each item is tagged with an owner, a volume estimate and a note on whether it is data, code or configuration. The step is done when the list is signed off by finance and operations, and every custom item has a named decision: rebuild, replace with standard functionality, or retire.
Decide the target version and hosting
The team chooses the target release line on each platform and confirms its support window before mapping starts. For ERPNext, check the supported versions page and whether the team will self-host with Docker or bench, or use Frappe Cloud. For iDempiere, check the current LTS release and the release branch the team will build on, and confirm the Java, database and application server versions with the community or implementation partner. The output is a written decision record naming the version, hosting model and database engine.
Map chart of accounts, items and bills of materials
Finance and the implementer build a mapping workbook that links each source account, item, unit of measure, warehouse, customer, supplier and bill of materials to its equivalent in the target. Differences in how each system models dimensions, tax codes, costing methods and multi-currency balances are recorded as explicit decisions, not left for the import to resolve. Open transactions such as unpaid invoices, purchase orders, work orders and stock on hand are mapped to a cutover date. The step is done when finance signs the mapping and every source field has either a target or a documented reason for dropping it.
Load master data and open balances in a test environment
Master data moves first. In ERPNext, the Data Import tool loads and updates records from CSV or Excel files using downloadable templates and handles child table rows, but its documentation advises importing only a few thousand records at a time, so large item or ledger sets need batching and a check of tool limits for your volume. In iDempiere, load data through the implementer's chosen method, such as SQL or a scripted loader, and confirm it against the same mapping workbook. Opening balances are posted as journal entries so the trial balance ties to the source. The output is a test environment whose record counts and balances match the source report by report.
Rebuild customizations on the target
Custom reports, plugins, server scripts, integrations and workflows are rebuilt on the target platform rather than copied across. In ERPNext, server-side Python scripts are disabled by default from version 15 and must be enabled through the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so hosting choice affects this step. In iDempiere, extensions are OSGi plugins written in Java and must be built against the chosen release. Each rebuilt item is tested against the inventory list from step one. The step is done when every item is marked rebuilt, replaced or retired, with test evidence attached.
Run a full test migration and reconcile
The full sequence runs at least once against a copy of recent source data. The team checks trial balance, aged receivables and payables, inventory valuation, open orders and production orders, and runs the month-end and period-close routine on the test system. Differences are logged with a root cause and a fix, and the migration script is rerun until the reconciliation is clean. Confirm with the vendor or community whether your data volume needs staged loads. The output is a reconciliation pack signed by finance and the business owner.
Cut over with a frozen source
At the agreed cutover point, transactions in the source system are frozen, final delta data is extracted and loaded, and the opening balances are posted on the target. Users are trained on the new screens and the old system is set to read-only. Backups of both systems are taken before and after the cutover, and a documented rollback path is kept until the business signs off. The step is done when the target has passed the same reconciliation checks as the test run and the first day of live transactions has been reviewed.
Run in parallel and retire the source
For a defined period, the team compares key outputs from both systems, such as invoices, stock movements and close reports, and resolves gaps as they appear. Integrations are monitored for failed messages and reruns. Once the business owner accepts the results, the source system is archived with read-only access for audit and retention needs, and its scheduled jobs and integration credentials are disabled. The output is an archive record and a closed migration log that confirm the source is no longer used for live transactions.
Where ERPNext and iDempiere implementation projects usually run long
Most overruns on both platforms start before any software is configured. On ERPNext and iDempiere alike, the expensive work is data cleansing, chart of accounts design and, for manufacturers, bills of materials and routings. Customer, item and supplier masters often arrive with duplicates and inconsistent units of measure. The ERPNext Data Import tool accepts CSV or Excel files and child table rows, but its documentation advises importing only a few thousand records at a time, so large histories need staged loads and reconciliation. On iDempiere, the chart of accounts and accounting schema are harder to change once transactions post, so the business owner for finance should sign off the account structure before a go-live date is set. Ask any partner which cleansing rules, reconciliation reports and opening balance checks will be tested with a copy of your real data, and how many load cycles that testing assumes.
Integration and reporting usually take more time than the core modules. Warehouse, shop floor and identity integrations need interface contracts that name the fields, units, error handling and owners on each side. On ERPNext, custom logic often starts as Server Scripts, which are disabled by default from version 15 and must be enabled through the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so confirm early whether your hosting permits them. Identity integration should be tested with the LDAP guide and social login settings the vendor documents, along with your own role mapping. On iDempiere, the plugin work runs through OSGi bundles, which means Java developers must build, deploy and test each change. Custom reports and user training often slip last. Each process needs a named business owner who approves the report definitions and signs off the training material, because unowned processes are where scope quietly grows.
Client-side skills and a test environment determine how much of this risk you carry. ERPNext customization is Python and JavaScript on the Frappe Framework, while iDempiere customization is Java with ZK and OSGi on PostgreSQL or Oracle, so confirm which of these skills your team or partner holds before choosing. Both projects need a separate test environment that mirrors production versions, a refresh process for test data and a way to promote changes. Because DeployOpen works on fixed-scope, written agreements, the statement of work should list deliverables, the test data used for acceptance, the responsibilities of your business owners and what happens when a change request arrives. Ask for these terms in writing before work starts.
Questions buyers ask before choosing ERPNext or iDempiere
How much does an ERPNext or iDempiere implementation cost?
No public figure exists for an implementation of either platform, so the cost depends on the written scope. The software itself is free to use: ERPNext is GPL-3.0 and iDempiere's repository is GPL-2.0. The recurring and one-time costs come from the people and hosting around it: a partner or internal team for configuration, data migration, custom development, integrations, testing and training, plus servers, backups and support. Costs rise with the number of legacy systems to migrate, the amount of custom Server Scripts or Java plugins, the number of sites or entities, and the depth of accounting and manufacturing setup. For ERPNext, the ERPNext pricing page lists Frappe Cloud hosting and says implementation is available through certified partners. Ask any provider for a fixed-scope quote that separates one-time work from annual support and hosting.
How long does an ERPNext or iDempiere project take?
Duration depends on scope, not on the platform name alone, and no supplied timeline applies to either product. The main drivers are the number of modules going live, the volume and quality of master data to clean, the number of integrations, and how many approval rounds the business needs. Your team must provide a named process owner for finance, inventory and production, access to current data extracts, decisions on chart of accounts and costing methods, and test users for each process. ERPNext's Data Import tool handles CSV, Excel and public Google Sheets, but the documentation advises importing only a few thousand records at a time, so large histories need planned batches. Ask the provider to show milestones, test cycles and the client tasks each milestone depends on.
Can our team run ERPNext or iDempiere without outside help?
A team can run either platform in-house, but it needs people who can operate the stack, not only use the screens. For ERPNext, self-hosting uses the bench command line tool, Docker Compose through frappe_docker, or Frappe Cloud. The production images include MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx, so someone must own upgrades, backups and monitoring. iDempiere requires Java, Maven, OSGi and the ZK framework plus PostgreSQL or Oracle administration. Most mid-sized firms use a mix: internal administrators for daily operations and an implementation partner for configuration, custom code and upgrades. Confirm which parts your staff will own before you sign, and ask the provider to document runbooks as part of the scope.
Which ERP suits a team with Python skills or a team with Java skills?
A Python-skilled team will usually find ERPNext easier to extend, while a Java-skilled team will find iDempiere more familiar. ERPNext is built on the Frappe Framework, a Python and JavaScript framework licensed under MIT, and Server Scripts let developers run Python on document events or as API endpoints. Since version 15, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. iDempiere is built with Java, ZK, OSGi and Maven, and extends through OSGi plugins. The better choice depends on which language your engineers will maintain for the next several years, because that person will carry the customizations.
Does Frappe Cloud remove the need for in-house operations?
Frappe Cloud reduces operational work but does not remove responsibility for the business. According to the ERPNext README, Frappe Cloud handles installation, upgrades, monitoring and support. Your team still owns configuration, user access, data quality, process decisions and testing of each release. Frappe's supported versions policy also states that customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Frappe Cloud shared site hosting starts at 5 US dollars per month, and servers start at 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers, according to the ERPNext pricing page. Check whether custom apps and Server Script limits fit the plan before you commit.
How hard is it to switch away from ERPNext or iDempiere later?
Switching is possible from either platform, but the effort depends on how much business logic sits in custom code. Both are GPL-licensed, so the software carries no per-user license fee to exit, but data export, custom app code, reports, integrations and retraining are the real costs. Keep an export plan from day one: ERPNext records can be exported and re-imported through the Data Import tool in batches, and iDempiere data sits in PostgreSQL or Oracle, which your DBA can extract. Document every customization, keep it in version control, and avoid hard-coding process rules that only one platform can express. Ask any provider to include a data-exit procedure in the written scope.
What are the iDempiere support windows, and who confirms them?
The supplied facts do not state iDempiere's support windows, so confirm them directly with the iDempiere project before you commit. What is known: iDempiere 13 "Orion" is a long-term support release, announced on the iDempiere website in a post dated March 12, 2026, and the repository keeps release branches from release-9 through release-13. Ask for the end-of-support date of the version you will deploy, the security patch policy, whether patches are published for older branches, and who provides them. If you use a commercial implementation partner, ask them to put support obligations for the chosen version in the written scope, so that responsibility is clear.
How DeployOpen helps choose, implement or migrate between these platforms
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ERPNext vs iDempiere, we start from your module needs, your accounting and manufacturing workflows, and the Python or Java skills your team already has.
How we scope
- We confirm which modules, accounting processes and manufacturing or distribution workflows the ERP must cover.
- We record hosting constraints, identity integration needs and the team's in-house Python or Java skills in writing.
- Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed before any work starts.
How we build
- We install and configure the chosen platform in your infrastructure, with the database and runtime versions your target release requires.
- We customize and integrate the ERP with your existing systems, then test data imports, accounting results and user workflows.
- We run security hardening and produce the configuration and evidence records your internal reviewers will ask for.
How we hand over
- We document the installed architecture, customizations, backup routines and upgrade steps so your team can operate the system.
- We walk your administrators and developers through the codebase, configuration and release process for the platform you chose.
- Handover includes a written record of what was delivered against the agreed scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can plan upgrades around the vendor's published support windows for the release line you run.
- Support scope, response expectations and upgrade responsibilities are confirmed in writing before a retainer begins.
