How to use an ERP requirements checklist before choosing Odoo or ERPNext
An ERP requirements checklist turns business processes into testable requirements before anyone chooses a platform. Finance and operations leaders who skip this step tend to compare Odoo and ERPNext on feature lists, then discover late that the feature they need sits behind a different edition, hosting route or support plan. The work runs in three passes: capture each requirement in plain operational terms, verify it with the platform vendor or an implementation partner, and only then score Odoo Community, Odoo Enterprise or ERPNext against the verified list. The checklist covers functional, security, integration, operational and compliance requirements. Most of them decide the edition or hosting route, not only which features appear in a demo, so they belong at the start of the selection.
Start with the requirements that change the architecture. Record every legal entity, the currencies and tax regimes each one uses, whether intercompany flows exist, and whether all entities must sit in one database. These answers determine whether multi-company functionality is needed, which in Odoo is only available on the Custom plan according to Odoo's pricing page, so confirm the entity count and plan with Odoo before drafting the scope. Next, list the modules in scope for accounting, inventory, purchasing, sales, manufacturing and projects, and note where each process is standard and where a local rule forces a change. Write each custom rule as a test a user can run, such as a three-way match that blocks payment when quantities differ. Ask the platform owner which rules need configuration, which need custom code and which need Server Scripts, since ERPNext disables Server Scripts by default from version 15 onward.
Then capture the requirements that govern operations over time. Record the number of historical transactions to migrate, the years of open items and balances you must carry, and what must be archived instead, because the answer drives import tooling and batch sizes. Define user roles and approval limits, the identity provider for single sign-on or directory integration, and how audit logs must be retained. Set a customization limit and a written upgrade path for any custom module, since Odoo major versions on Odoo Online and Odoo.sh are mandatory every two years and on-premise upgrades require an Enterprise subscription. For regulated firms, map controls to the rules you already answer to, for example the logging and multi-factor authentication expectations in the FTC Safeguards Rule at 16 CFR 314.4 or the record retention in 17 CFR 240.17a-4. Ask each vendor and partner to confirm these items in writing before you score them.
Which ERP functional requirements to write down first
This table lists the ERP requirements to fix before choosing Odoo or ERPNext, with why each one affects the platform and how to test it. Read it as a pre-selection checklist: the entity count and multi-company needs can change the platform choice early, so verify those first.
| Requirement | Why it matters to the choice | How to verify it |
|---|---|---|
| Legal entities and multi-company needs | Odoo multi-company is listed only on the Custom plan in the pricing page, so the entity count can decide the plan. ERPNext handles companies inside one site, which suits some groups but not all. | Write a company and intercompany map with entity names, countries and flows, then ask each vendor or partner to confirm the setup in writing. |
| Chart of accounts per entity | Separate charts of accounts or shared charts change how reporting, consolidation and audit trails are built. | Ask for the existing charts of accounts and run a scripted demo that posts one intercompany invoice across two entities. |
| Currencies and localization | Multiple currencies, local tax codes and statutory reports can require localization packages that differ by country and version. | List currencies, tax regimes and statutory reports per country, then confirm each localization exists for the target version in writing. |
| Modules in scope | Each module choice (accounting, inventory, manufacturing, projects, HR) affects edition, plan and integration work. Scope creep is common when modules are not listed up front. | Mark each process as in scope, out of scope or later phase, and walk each in-scope process through a demo using your own sample documents. |
| Inventory and manufacturing processes | Stock valuation, lot tracking, bills of materials and work orders need to match how goods actually move. Gaps here are costly to fix after go-live. | Run a fit-gap workshop with warehouse and production leads, using real order, receipt and production records as test cases. |
| Reporting and close requirements | Required reports, close calendar and drill-down needs determine data model and reporting tools. Vague requirements produce rework late in the project. | Collect the report catalogue and sample outputs, then ask the vendor or partner to reproduce two or three of them in a demo. |
| User roles and segregation of duties | Role design controls who can post, approve and change master data. Roles also affect how access is evidenced to auditors. | Draft a role matrix with approval limits, then test it with sample users in a non-production copy and record the results. |
| Customization limits and upgrade path | Odoo Studio, external API access and custom modules are listed only on the Custom plan, and custom code must survive version upgrades. ERPNext server scripts are disabled by default from version 15 and must be enabled. | Ask for a written list of customizations allowed by the chosen plan or version, and require a test upgrade of one custom module before sign-off. |
How Odoo editions and ERPNext change the requirements you can meet
Odoo Community is the open source core of Odoo, published under the LGPL-3.0 license and available on GitHub. It gives you the business applications in the open source edition, so it suits teams that want the source code, want to run it inside their own infrastructure and can carry the operating work themselves. The limits matter as much as the license. Odoo's documentation says the Community edition has no access to the upgrade service, and the Enterprise source code is not public, so features that exist only in Enterprise are not available here.
- Source and license: The core is LGPL-3.0, so you can inspect, modify and run it under the license terms.
- Upgrades: The upgrade service requires an Enterprise subscription for on-premise use, so you need your own upgrade plan for each major version.
- Support path: Odoo's standard and extended support terms apply to the Odoo products it sells, so plan support from a partner or in-house team.
- Enterprise features: Mobile apps, Studio and version upgrades are Enterprise features, so mark any requirement that depends on them as a gap.
- Multi-company and API: Confirm in Odoo's plan documentation whether these are included in the edition you plan to run.
Before you commit, confirm the Community feature list against each line of your requirements list, including accounting localization, inventory and reporting needs.
Odoo Enterprise is a paid edition built on the Community core. Odoo's pricing page says only the Custom plan can be hosted on Odoo.sh or on-premise, and that the Custom plan is the one that includes multi-company, Odoo Studio, external API access and custom modules. For organizations that must self-host and need these capabilities, the Custom plan is the route to evaluate. Enterprise source code is not publicly available, so you access it through a subscription or partner access.
- Self-hosting: On-premise use requires an Enterprise subscription, activated with the subscription code on the database.
- Multi-company and API: Custom includes multi-company and external API access, which matter for group structures and system integrations.
- Custom modules: Custom includes custom module support, so requirements that need code beyond standard apps can be assessed here.
- Standard support: Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates.
- Extended support: Paid extended support after that is limited to Odoo.sh for select versions and on-premise, and security patches come only during standard support.
Before you commit, check the Custom plan's current terms and scope with Odoo, and confirm the support window for the version you target.
ERPNext is a free and open source ERP built on the Frappe Framework and licensed under GPL-3.0, with the framework under MIT. The ERPNext pricing page states that self-hosting is free, and that implementation is available through certified partners. It covers accounting, order and inventory management, manufacturing, asset management and projects. For self-hosted requirements, ERPNext can run on Docker Compose or manually with the bench command line tool, so it fits teams that want a full open source license without a paid edition tier.
- License: GPL-3.0 for ERPNext and MIT for the framework, which you should review with counsel for your distribution model.
- Version support: Frappe lists the supported versions and says warranty coverage requires a listed version and a matching Frappe Cloud support plan.
- Customization: Server Scripts are disabled by default from version 15 and must be enabled with
server_script_enabled, so plan custom logic accordingly. - Data import: The Data Import tool loads CSV or Excel files, and the documentation advises importing only a few thousand records at a time.
- Hosting choice: Self-hosting is free of license fees, while Frappe Cloud is a paid hosting option.
Before you commit, confirm the ERPNext feature list, localization and tax coverage for your countries, and the support model with a certified partner.
Which security requirements a financial ERP checklist must include
If your organization is a covered financial institution under the FTC Safeguards Rule, the ERP holds customer information and must meet specific technical controls. The cards below turn those controls into requirements you can write down before choosing Odoo or ERPNext, and each one names a check to run against the platform and your identity setup.
Encryption in transit and at rest
The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to encrypt customer information in transit over external networks and at rest. For an ERP, this covers browser and API traffic, database storage, backups, attachments and exports. Ask each platform route to show where encryption is configured, who manages the keys, and how backup copies and file storage are protected. Confirm whether your hosting provider or your own team holds these responsibilities.
Multi-factor authentication for all users
The Safeguards Rule requires multi-factor authentication for any individual accessing any information system, which includes finance staff, administrators, vendors and service accounts that reach the ERP. Write down which accounts need MFA, where it is enforced (the identity provider or the application), and what happens to API tokens that bypass interactive login. Verify these settings in the test environment before the rollout is approved.
Identity integration with LDAP or social login
Odoo offers LDAP authentication, and ERPNext documents LDAP integration and social login keys. Both can connect the ERP to your corporate directory so that joiners, movers and leavers are handled in one place. Confirm with your identity provider whether it supports the LDAP bind pattern you need, whether MFA is enforced upstream, and whether the edition you plan to run includes the feature. Test deprovisioning, because a disabled directory account must also end ERP access.
Change management for configuration and code
The Safeguards Rule requires change management procedures. In an ERP, changes arrive as configuration edits, custom module releases, workflow updates and database patches, and each can alter financial results. Define who approves each change type, where it is tested before production, and how the change is recorded. Ask the partner how custom code moves between environments and how a rollback is performed if a release breaks posting.
Activity logging for authorized users
The Rule requires covered institutions to log the activity of authorized users. For a financial ERP, the log should capture postings, approvals, user and role changes, exports, and changes to settings. Confirm what each platform records by default, how long logs are kept, where they are stored, and whether they are protected from edits by the administrators they monitor. Match the log retention to your records policy, including any longer period set by other rules that apply to your business.
Server Scripts and custom code controls
In ERPNext, Server Scripts run Python on document events or as API endpoints. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Treat any enabled script as custom code under change management, and decide whether your build needs them at all before selecting a hosting route that permits them.
Penetration tests and vulnerability assessments
Under 16 CFR 314.4(d)(2), if you do not have effective continuous monitoring, you must run annual penetration testing and vulnerability assessments at least every six months. Put the ERP, its APIs, its integrations and its hosting in the test scope, and agree in writing who tests, what is excluded, and how findings are tracked to closure. Ask whether the platform vendor's testing is shared with you, and confirm that test results can be shown to your examiners.
How the upgrade path shapes custom module requirements
Custom modules and customizations are only as durable as the upgrade path underneath them, so the requirements checklist should record the supported-version window before any custom code is written. In Odoo, standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Odoo 20.0 was released in September 2026 with standard support planned until September 2029, while Odoo 17.0 standard support ended in September 2026. Odoo Online and Odoo.sh also require major version upgrades every two years, so a custom module built for one major version will need to be ported on a fixed cadence. For on-premise deployments, the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. Ask every bidder which Odoo edition and hosting route the requirements assume, and confirm whether that route includes the upgrade service.
ERPNext and the Frappe Framework follow a different window. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Frappe's policy also ties warranty coverage to running a listed version and holding a matching Frappe Cloud support plan, so a self-hosted site without that plan should not assume vendor-backed fixes. Before you finalize custom app requirements, confirm which major version the site will run at go-live and when it leaves support, and check whether your implementation partner will maintain the custom apps through each major upgrade.
Write the upgrade budget and the supported-version window directly into the requirements document. At minimum, record the chosen major version, its end-of-support date, the planned upgrade dates, the number of custom modules or apps that must be re-tested at each upgrade, and who pays for that work under the support contract. Ask partners to price upgrade cycles separately from initial build, and to state whether custom code will be reviewed against each new release before cutover. Requirements that name the support window, not just the feature list, let you compare build options on the same terms and avoid discovering in year three that a customization blocks an upgrade.
Which integrations to capture before the platform is chosen
Every integration on the list below needs the same four answers before an ERP is chosen: which way the data moves, how often, who owns each system, and whether the chosen plan or edition exposes the API it needs. Capture these per integration so the platform decision is tested against real traffic, not assumptions.
Bank statement feeds and reconciliation
Identify every bank account, the file format or connection each bank provides, and whether statements arrive intraday or once a day. Record who approves the reconciliation and where the bank data lands in the ledger. Ask for sample statement files from each bank and check that the ERP can import them, match transactions and retain originals for the retention period your regulator sets.
Payment processors and payouts
List each processor, the direction of settlement files and webhooks, and the frequency of payout reports. Name the owner of the processor account and the finance owner of the matching logic. Confirm whether card data ever enters the ERP. If it does, the integration widens your compliance scope, so keep the ERP to settlement references and totals wherever possible.
E-invoicing and tax reporting
Document which invoices must be issued or received electronically, which tax authority or intermediary receives them, and the filing calendar for each jurisdiction. Confirm with your tax advisor and the platform's localization documentation whether the required formats are supported natively or need a custom module. Test with sample invoices from your own customers before assuming compliance.
CRM and billing systems
Map which system owns customers, quotes, subscriptions and invoice generation, and in which direction each record flows. Decide the frequency for each sync, such as real time for orders and daily for customer master data. Ask whether the ERP needs external API access, which Odoo includes only in its Custom plan per the pricing page, and test the sync with your own sample orders in a trial.
Identity providers and access
Record which directory issues user accounts, who owns joiner and leaver processes, and whether roles must be synced automatically. Odoo documents LDAP authentication, and ERPNext documents LDAP integration and social login keys. Confirm both options against your identity provider's version and test group mapping with a sample set of users before go-live.
Reporting and data warehouse exports
Define which datasets leave the ERP for the warehouse or board reporting, their refresh frequency, and who owns the data definitions. Check whether the platform provides scheduled exports, database read access, or only a manual export, and whether those exports include the audit fields your controllers need. Validate row counts and totals against sample extracts from your own trial data.
Which operational requirements decide hosting, support and recovery
This table lists the operational requirements that decide where an ERP runs, who patches it, and how it recovers, with a verification method for each. Read each row as a question to answer in writing before choosing Odoo or ERPNext, because the answers often rule out an edition or plan. The main takeaway is that hosting, support and release cadence are contract and architecture decisions, not details to settle after go-live.
| Requirement | What to decide or confirm | How to verify |
|---|---|---|
| Hosting location and data residency | Which country or data center holds financial and employee records, and whether Odoo Online, Odoo.sh, on-premise or self-hosted ERPNext is allowed there | Written hosting map from the vendor or partner, checked against your data residency policy and the edition or plan that supports that location |
| Environments (production, test, training) | How many non-production environments you need, who refreshes them, and whether training data can contain real customer or employee records | Environment register with owners and refresh dates, plus a rule that test copies are sanitized before use |
| Test copies and data neutralization | Whether test databases are copies of production and how sensitive fields, emails and payment details are removed before testers log in | Odoo documents database duplication with neutralization for test copies; run a sample copy and confirm that outbound emails and integrations are disabled |
| Backup and restore testing | Backup frequency, retention period, storage location, encryption, and the recovery time and data loss your finance team accepts | Restore a recent backup to an isolated copy, reconcile trial balances and open items, and record the elapsed time and any gaps |
| Monitoring and alerting | Which signals are watched (service availability, background jobs, scheduler, database capacity, failed integrations) and who responds out of hours | Written monitoring scope from the partner, test alerts with a simulated failure, and a sample incident record |
| Release cadence and upgrade path | Odoo SaaS versions are released every two to three months and cannot use extended support; ERPNext ships frequent minor releases on supported majors | Review the vendor release schedule against your change calendar, and agree how custom modules are retested before each upgrade |
| Version support windows | Which major version you run and when its standard support ends (Odoo 17.0 standard support ended in September 2026; Odoo 20.0 standard support is planned until September 2029) | Check the vendor support page on the day you sign, and record the end-of-support date in the project plan |
| Support hours and escalation | Business hours, severity levels, response expectations and whether support covers the custom modules you build | Written support matrix from the vendor or partner, with named escalation contacts and a signed scope that lists what is excluded |
| Security patches and who applies them | Whether the vendor, the partner or your team applies security updates, and how quickly after publication | Patch responsibility matrix in the contract, plus a dated log of the last patch applied to each environment |
| Records retention | How long ledgers, bank statements, invoices and business communications must be kept, and whether archived data stays readable after an upgrade | Map each record type to its retention rule with your compliance lead, then perform a test retrieval from the archive after a restore |
How to verify ERP requirements before a vendor demo
This sequence turns a draft list of ERP needs into tested evidence, so each candidate is judged on the same scripted processes and your own data rather than on a polished demo.
Rank each requirement as must-have or nice-to-have
Start from the requirements you captured across entities, currencies, modules, inventory and manufacturing, integrations, migration, reporting, roles and customization limits. Mark each item as must-have or nice-to-have and bring a short reason for every must-have, such as a legal filing, a close deadline or an existing integration. Done means every line carries one of the two labels and a named reason for each must-have, so that scoring later cannot drift.
Name a process owner for each area
Assign one accountable person from finance, operations, sales, IT and compliance to each requirement area, and bring the list of people who run those processes today. Owners decide what counts as a passing answer in their area and who signs off the scenarios. Done means every must-have has an owner who has agreed to review results in writing.
Prepare a sample dataset from the current system
Extract a representative set of customers, vendors, products, open invoices, bank lines and a few months of transactions from the system you are replacing, including the awkward cases such as partial payments, multi-currency items and returns. Keep it anonymized or inside your own controlled environment if it contains personal data. Done means the dataset is documented with record counts and known exceptions, and the owners have confirmed it reflects real volumes.
Write scripted scenarios for the top processes
Turn the highest-priority must-have processes into step-by-step scripts with inputs, expected outputs and the report or journal entry that should result. Include at least one scenario per integration and one per month-end or period-close task. Done means each script names its owner, its input records from the sample dataset and the exact result that counts as a pass.
Send the requirements to each candidate for written answers
Send the ranked requirement list to every candidate and ask for written answers that state whether each item is standard functionality, configuration, a custom module or a third-party add-on. Ask for the edition or plan that includes each feature, because capabilities differ across Odoo plans and between Odoo and ERPNext. Done means every must-have has a written answer with a classification and a named source for the claim.
Run the scenarios in a trial environment
Load the sample dataset into a trial or test instance for each shortlisted candidate and have the process owners run the scripts themselves, not the vendor. Record pass, partial or fail for each step, with screenshots or output files as evidence. Done means every top scenario has a recorded result per candidate and no scenario was marked passed on a demo alone.
Record gaps with owners and a decision date
Log every failed or partial step as a gap with a severity, a proposed workaround such as configuration, customization or process change, and a named owner. Set a decision date with the steering group and confirm the cost and effort of each workaround through the partner's written quote. Done means every gap has an owner and a status, and the decision date is recorded in the project plan.
How much history to migrate and how long records must be kept
The amount of history to migrate is a requirement you set, not a default you inherit from the legacy system. Before any data is extracted, separate what must move into Odoo or ERPNext from what can stay behind as an archive. Open items (unpaid customer and supplier invoices, open purchase and sales orders, unreconciled bank lines, open fixed assets) and period-end opening balances must be loaded so the new ledger can run on its own. Full transaction history is different: it is useful for reporting and audit lookups, but it can usually be retained in a read-only archive that the finance team can query. Decide this per data set, record the decision in the requirements document, and confirm with the controller which years of detail the business will actually open in the new system.
Retention periods are a legal question, so confirm them with your legal and compliance team before you design the archive. As an example of what the rules can require, SEC Rule 17a-4(b) in 17 CFR 240.17a-4 requires broker-dealers to preserve records such as bills receivable or payable and bank statements for not less than three years, with the first two in an easily accessible place. If your organization is a broker-dealer or falls under similar rules, the migration plan must keep those records retrievable inside the window, which affects whether they go into the live ERP or a separate store. Document the retention schedule per record type, its owner, and how a regulator request would be answered.
Migration volume also shapes the plan. The ERPNext Data Import documentation advises importing only a few thousand records at a time, so a ledger with hundreds of thousands of invoice lines needs many batches, each with its own trial load and reconciliation. Count records per data set early, including child table rows such as invoice lines, and estimate how many trial runs the schedule can absorb. Ask any implementation partner to show the batch sizes, the reconciliation totals per batch, and the rollback method they will use. Odoo import behavior and limits should be confirmed in its current documentation and in a test database before you set the batch plan.
Questions buyers ask before hiring help with ERP requirements
How long does the ERP requirements phase take?
The length depends on scope, not on the software choice. The main drivers are the number of legal entities and currencies, how many process variants each department runs, the state of the data you plan to migrate, and how many stakeholders must agree on each decision. A single-entity business with one sales process and clean item and customer lists can usually close the phase faster than a group with several entities, separate warehouses and manufacturing sites. Ask any partner to show how they will time-box the phase and which decisions must be signed off before the fit-gap work starts, and ask for the timeline in the written scope rather than as a general estimate.
What must our team provide during requirements gathering?
The buyer must provide the people and the decisions, because no partner can make them for you. In practice this means:
- Named process owners for finance, sales, purchasing, inventory, manufacturing and reporting, with authority to approve changes to their process
- Sample documents and real data extracts, such as recent invoices, purchase orders, bills of materials, price lists and a chart of accounts
- A written list of decisions, such as which entity posts which transaction, how tax is handled, and who approves exceptions
- A named sign-off owner for each requirement set, so scope changes are visible and priced
If these people are not available for the planned sessions, the requirements phase will stretch, and the fit-gap results will rest on assumptions.
Can we write the ERP requirements ourselves?
Yes, for a small, single-entity scope with standard processes and limited customization. A finance or operations lead who knows the current process can document entities, modules, user roles and reports in a structured list. The work becomes harder when several legal entities share data, when records must meet regulatory retention or audit rules, or when you expect custom modules, because each of those adds dependencies that are easy to miss. In those cases, ask whether the requirement list will be checked against the standard features of the chosen edition, and whether the upgrade path for custom code has been written down before anyone commits to a build.
What does a partner add to the requirements phase?
A partner adds a repeatable method and an independent check on your assumptions. A typical fit-gap method compares each documented process with what the standard application does out of the box, then classifies each gap as configuration, integration, custom module or process change. Good partners also write verification scripts or test cases tied to each requirement, so the buyer can confirm during build and testing that the system does what the requirement says. Ask to see a sample fit-gap register and a sample test script, and ask how the partner records decisions that change scope after sign-off.
What determines the price of an ERP requirements engagement?
The price follows from the written scope: the number of entities, process areas, integrations, data sources to migrate, custom modules and stakeholder sessions. Software licensing and hosting are separate cost lines. For example, the ERPNext pricing page lists self-hosting ERPNext as free, while Frappe Cloud shared site hosting starts at 5 US dollars per month and Frappe Cloud servers start at 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers. Odoo prices per user and per plan, and only the Custom plan includes the multi-company, Studio, external API and custom module features that many scopes need. Ask any provider for a quote that separates one-time analysis work from recurring licenses, hosting and support, and that lists every assumption it depends on. DeployOpen works from a written scope and does not publish a price list.
Which requirements should we confirm with Odoo or Frappe before we choose?
Confirm the requirements that the license, plan or version decides, because those are hard to change later. For Odoo, check which plan includes multi-company, external API access, Studio and custom modules, and whether the planned hosting model (Odoo Online, Odoo.sh or on-premise) is available for that plan. Also check the support window for the version you intend to run, since standard support for Odoo 20.0 runs until September 2029 and Odoo 17.0 standard support has already ended. For ERPNext, confirm that the version you pick is on Frappe's supported versions list and check whether you need a matching Frappe Cloud support plan for warranty coverage. Record each answer with its date and source in the requirements document.
Does the requirements phase also cover security and compliance evidence?
It should, because access rules, audit logging and record retention are requirements, not later add-ons. Capture them as explicit items: which roles can approve payments, how segregation of duties is enforced, whether multi-factor authentication and single sign-on are needed, how change approvals will be recorded, and how long transaction records must be kept. Regulated businesses may need to map these items to rules such as the FTC Safeguards Rule at 16 CFR 314.4 or the SEC record-keeping rule at 17 CFR 240.17a-4, but your counsel and compliance team should confirm which rules apply. Note that DeployOpen prepares systems, controls and evidence for assessments, while independent auditors issue any audit report or attestation.
How DeployOpen scopes, delivers and supports ERP selection and implementation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. We start by turning the requirements in this checklist into a written scope, then build, test and hand over the chosen ERP with the evidence your teams and auditors will ask for.
How we scope
- We review your entity structure, currencies, localization needs and modules in scope against this checklist.
- We document which processes are configured standard and which need custom modules, with the limits stated in writing.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the selected platform in your cloud account, data center or air-gapped network, not in ours.
- We map data sources, define migration batches and run trial loads with reconciliation checks before cutover.
- We build custom modules with upgrade paths in mind and test them in a staging copy before production.
How we hand over
- You receive configuration records, integration designs, access role matrices and the test results for each area.
- We document change procedures, backup and restore steps and the upgrade plan for custom code.
- Your staff are trained on the admin tasks they will own after go-live, using the documentation we deliver.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any opinion.
- Support scope, response expectations and upgrade cadence are defined in the written agreement, not assumed.
