SAP / Odoo / Microsoft Dynamics Development

An ERP delivers standard processes for finance, purchasing, inventory and more. Development fills the gaps between those standards and the way your business really operates, or links the ERP to systems it does not natively connect to.

• Industry-specific documents, pricing or approval rules.
• Tailored screens and reports for warehouse, field or finance staff.
• Integrations with e-commerce, CRM, logistics and banking systems.
• Data import and export tools, and scheduled batch jobs.
• Extensions needed for local tax or statutory requirements.

If you have not yet selected or deployed an ERP, start with ERP implementation services. This guide assumes a system exists or is being chosen.

The way you change an ERP determines how expensive upgrades become. Treat these three categories differently.

The side-by-side route is close to the thinking behind the Strangler Fig pattern (opens in a new tab): leave the core stable and build new capability around it. Teams that follow this approach often describe the goal as keeping the standard core clean.

The products differ in architecture and licensing, and each vendor’s own documentation is the authority. These notes are general orientation, not a recommendation.

• SAP: SAP supplies large enterprise ERP products with their own development tools and a strong emphasis on keeping custom code separate from the standard system. Skills are narrow and in demand, so confirm exact product versions and tooling with the vendor before planning.
• Odoo: a modular business application suite whose functionality is organized as installable apps and modules, with a documented framework for creating your own. See the Odoo documentation (opens in a new tab) for the developer reference. It is offered in different editions and hosting options, so check which one you use.
• Microsoft Dynamics 365: a family of business applications with extension and low-code tooling, and strong ties to other Microsoft services. The Dynamics 365 documentation (opens in a new tab) describes customization and integration options, and Power Automate (opens in a new tab) covers workflow automation.

ERP integrations carry orders, stock levels, invoices and master data, so mistakes are costly. Treat integration as a core part of ERP development services and design it before building.

• Decide the source of truth for each entity, such as product or customer.
• Prefer APIs and events over database-level access, which bypasses the product’s business rules.
• Handle failure: retries, duplicate protection and alerts when a message fails.
• Document interfaces with the OpenAPI Specification (opens in a new tab) where you expose REST services.
• Secure each endpoint against the issues listed by the OWASP API Security Project (opens in a new tab).

The Enterprise Integration Patterns (opens in a new tab) catalog is a good reference for message routing and transformation. Larger programs belong with enterprise application integration teams, and process automation around the ERP can be handled through workflow automation.

The hidden cost of ERP customization is the work required after each vendor update. Plan this from the first change.

1. Specify each requirement with a business owner and an acceptance test written in plain language.
2. Build in a development environment, with version control and peer review.
3. Test in a staging copy that contains representative, anonymized data.
4. Run regression tests across related processes, such as an order to invoice to payment cycle.
5. Release with a rollback plan and communicate to users beforehand.
6. Retest on every vendor release, before it reaches production.

Keep a register of every extension with its purpose, owner and dependencies. Retire extensions whose purpose has gone away.

A new approval screen changes someone’s daily routine, so treat each significant extension as a small change program. Involve the users who will operate it in design reviews and testing, not only the manager who requested it.

Provide short, role-specific guides and a visible contact for questions. After release, review whether the new step is actually used and whether errors dropped. If staff are bypassing a customization, that is a design signal, not a training failure alone.

• Manufacturing: a custom quality-inspection step that blocks release of a batch until checks are recorded.
• Wholesale distribution: customer-specific price agreements pushed from the ERP into an online ordering portal.
• Construction and projects: a progress-billing screen that links site milestones to invoices.
• Healthcare supplies: lot and expiry tracking connected to purchasing and a regulatory reporting export.

These are illustrative examples of typical extension work, not Kramate client results.

Localization in ERP covers tax, statutory reporting, payroll and language. Confirm details with legal counsel and your accountants.

• USA: multi-state sales tax and audit-trail expectations, particularly for listed companies; state privacy laws apply to personal data held in the ERP.
• UK: VAT, digital record-keeping requirements and UK GDPR obligations, with the Information Commissioner’s Office as regulator.
• Australia: GST, payroll reporting and the Privacy Act 1988; confirm whether local localization packs cover your needs.
• Singapore: GST and Personal Data Protection Act obligations, with local formats for invoices and filings.

Check that any vendor localization package is current before relying on it, and agree developer support hours that fit multi-region operations.

Development cost rises with complexity and with the number of other systems touched.

• Number and complexity of custom modules and reports.
• The ERP family, edition and version, and the scarcity of the relevant skills.
• Number of integrations and quality of the external APIs.
• Testing environments and regression-test coverage.
• Data migration or cleanup tied to the change.
• Ongoing maintenance and upgrade compatibility work.

Fixed-price suits defined modules; a dedicated team suits a rolling backlog; hourly suits fixes and advisory work. Budget separately for upgrade testing each year. Licenses are paid to the vendor and are outside the development estimate.

1. Product-specific depth, shown by naming versions, tooling and extension methods.
2. Preference for supported extension points over modifying the core.
3. Testing discipline: staging environments, regression tests, release notes.
4. Integration track record with systems like yours.
5. Documentation and knowledge transfer so you are not dependent on one developer.
6. Ownership terms: you own custom code and configuration.
7. Upgrade support plan after the first release.

Kramate can lead the work or embed engineers in your IT team. Expect a dedicated project manager, daily Slack or Teams updates, a demo at the end of each two-week round and an NDA before detailed talks. Secure practices include least-privilege access, encrypted devices, peer code review and regular security testing, and all intellectual property transfers to you. The full process is described in our approach.

• Strangler Fig Application (opens in a new tab)Martin Fowler
• Odoo Documentation (opens in a new tab)Odoo
• Dynamics 365 documentation (opens in a new tab)Microsoft
• Power Automate documentation (opens in a new tab)Microsoft
• OpenAPI Initiative (opens in a new tab)OpenAPI Initiative
• OWASP API Security Project (opens in a new tab)OWASP
• Enterprise Integration Patterns (opens in a new tab)Gregor Hohpe