Existing systems guide
How do you build an application on top of an existing ERP or CRM?
Keep the ERP or CRM as the system of record for the capabilities it owns. Add a stable application and integration layer that presents a better experience, orchestrates only the necessary workflow and protects both sides from change.
The direct approach
Define the customer or staff workflow the current ERP or CRM does not serve well. Map the records and rules the source system must continue to own. Build the new application against an integration boundary that translates source-specific identifiers, fields, errors and events into a stable application model.
Deliver one complete workflow first. This reduces the risk of a large replacement and creates a practical path for incremental modernisation. AWS describes the strangler fig pattern as gradually placing new capabilities around a legacy system and replacing selected functions over time rather than relying on a single high-risk rewrite. The guide to modernising a business system without replacing it explains the wider decision and coexistence plan.
01
Extend when the core works but the experience does not
| Situation | Likely response |
|---|---|
| ERP owns reliable transactions but customer access is poor | Add a customer application over supported operational interfaces |
| CRM tracks accounts but a service workflow lives in email | Add a workflow application and synchronise key status and ownership |
| Staff re-enter the same information across systems | Create a guided application and integration orchestration |
| Core platform can configure the whole requirement cleanly | Configure before introducing another application |
| Core data and rules are fundamentally unreliable | Stabilise ownership and quality before exposing a polished new layer |
| Platform is unsupported and blocks every material change | Plan staged replacement, using the new boundary to reduce migration risk |
02
Write down which system owns each decision
ERP or CRM
Source record
Owns the authoritative customer, order, invoice, case or account fields already governed there.
Application
New experience
Owns navigation, interaction state and rules unique to the added workflow.
Integration
Translation and delivery
Maps identifiers, validates contracts, carries commands and events, and handles failure.
Operations
Exceptions and support
Owns reconciliation, retries, corrections, access administration and customer communication.
A field should not become authoritative in two systems by accident. For every write, define the owner, validation path, acknowledgement, conflict behaviour and audit record.
03
Choose an integration pattern per capability
| Pattern | Best for | Trade-off |
|---|---|---|
| Live API | Current reads and supported immediate transactions | Experience depends on source latency and availability |
| Event subscription | Reacting to source changes without repeated polling | Requires ordering, replay, duplicate and missed-event handling |
| Queued command | Long-running or failure-prone writes | Needs durable customer status and operational retries |
| Read model or cache | Fast search, combined views and source isolation | Creates freshness and reconciliation responsibility |
| Scheduled extract | Legacy systems with batch interfaces | Limits freshness and complicates corrections |
| Vendor extension | Workflow tightly coupled to supported platform capabilities | May increase platform dependency and upgrade constraints |
Hide these patterns behind application-oriented services. A customer screen should ask for an order summary or submit a service request, not understand a vendor table or proprietary endpoint.
04
Design writes as business workflows
- use a business request identifier to prevent accidental duplicates;
- preserve the acting user and organisation through the integration path;
- separate received from completed when processing is asynchronous;
- map source errors to useful customer or staff messages;
- route unresolved exceptions to a named operational owner;
- reconcile final source state rather than assuming delivery means success; and
- avoid updating a local copy optimistically when the core may reject the transaction.
05
Assume the existing system will be slow, unavailable or change
- Timeouts: stop waiting within a defined customer experience budget.
- Retries: retry only safe failures with limits and backoff.
- Queues: preserve accepted work when immediate completion is not required.
- Circuit breaking: avoid multiplying pressure on an unhealthy dependency.
- Contract tests: detect source interface changes before customers do.
- Adapters: contain vendor-specific structures and error behaviour.
- Observability: correlate one user action across application, integration and source.
When the source is unavailable, show an honest state and a useful next step. Silent failure or false success transfers technical uncertainty directly to the customer.
06
Keep customer and integration trust separate
The customer authenticates to the new application. The application uses a constrained integration identity to the ERP or CRM. Do not forward customer-controlled identifiers or permissions and expect the source interface to repair the access decision.
- resolve user, organisation and role on the application server;
- authorise each record and action before calling the source;
- use least-privilege credentials per integration environment;
- return only approved customer-facing fields;
- protect support elevation and privileged administration;
- audit sensitive reads, writes and access changes; and
- test cross-customer identifiers through every adapter and cache.
Use the guide to securely expose business data to customers for the wider control model.
07
Modernise through one complete slice
- Measure the current workflow and choose one valuable friction point.
- Confirm source ownership, supported interfaces and operational owners.
- Prototype the hardest read, write and identity-mapping assumption.
- Introduce an adapter and stable application contract.
- Build the experience, administration, exception and monitoring path together.
- Pilot with real data, roles, volume and at least one source-system failure.
- Expand only after measuring completion, support effort and reconciliation quality.
Read the client portal integrations guide for a broader comparison of APIs, events, queues and synchronisation, or use the integration-layer design guide when several applications share the boundary.
Sources
Primary reference
Questions
Frequently asked questions
Can you build a custom application on top of an ERP or CRM?
Yes. Keep the ERP or CRM responsible for the records and rules it handles well, then add a separate application layer for the new customer or operational experience. Connect through supported APIs, events, queues, governed extracts or carefully controlled database interfaces.
Should the new application copy ERP or CRM data?
Copy only when a read model, cache, search index or integration store provides a clear performance or resilience benefit. Document which system owns each field, how changes synchronise, how conflicts are resolved and how copied data is retained.
What if the existing system has no API?
Evaluate supported exports, scheduled files, integration middleware, read-only database access, vendor extension points or robotic automation as a last resort. Wrap unstable access behind an adapter so the new application does not depend directly on legacy details.
Where should new business rules live?
Rules that govern the source record should normally remain in or be enforced by the owning system. Rules specific to the new application workflow can live in the application layer. Document the boundary to avoid contradictory decisions.
Do you need to replace the ERP or CRM later?
Not necessarily. The application can remain a stable experience while source systems evolve. A well-defined integration boundary also makes incremental replacement easier if the business later chooses to modernise the core.
Extend an existing system
Bring the current workflow, platform constraints and customer need.
LCR can help define a safe extension boundary and prototype the highest-risk ERP or CRM integration before the wider application build.