You have Dynamics 365 deployed. You also have an ERP from fifteen years ago, a proprietary WMS, and a SQL database nobody dares to touch. The question is not whether you can connect them — it’s how to do it without setting up a manual ETL process that breaks every time someone changes a field. Real-time data integration between Dynamics 365 and legacy systems is one of the most frequent challenges in digital transformation projects in LATAM, and also one of the ones that most often stalls projects when approached without a clear architecture. Connecting modern platforms with legacy systems requires architectural decisions that go far beyond writing a synchronization script. Poorly planned data integration can cost more in maintenance than the legacy system it is meant to replace.
Why manual ETL is no longer a viable option
For years, the standard model was to extract data from system A, transform it in a script, and load it into system B. It worked when processes were slow and data did not need to arrive within minutes. ETL-based data integration running overnight was sufficient in that context. Today, that approach has three critical problems.
First, latency is incompatible with real-time decisions. An overnight ETL process means your sales team is working with yesterday’s stock. Second, maintaining custom scripts becomes accumulated technical debt: every schema change in the legacy system breaks the data integration pipeline. Third, traceability is almost nonexistent — when it fails, nobody knows exactly which record was not synchronized or when.
Modern synchronization does not eliminate transformation; it shifts it to a managed, monitored, and recoverable layer. A well-designed data integration pipeline turns every flow into a maintainable asset, not a technical burden.
The ecosystem map: what Dynamics 365 makes available to you
Before choosing a connection pattern, it is worth understanding what Dynamics 365 exposes natively. The platform offers three main surfaces that determine the entry point for any hybrid data integration architecture.
OData Web API and Dataverse
The OData Web API is the standard RESTful interface for Dynamics 365 Customer Engagement and Dataverse. It allows full CRUD operations on entities, filtered queries, and relationship expansion. For inbound flows — when an external system needs to create or update records in D365 — it is the most direct entry point for any data integration process.
Dataverse acts as the unified data layer underlying all Dynamics 365 applications. Any data that reaches Dataverse is automatically available to Power BI, Power Apps, and Copilot, which turns every data integration pipeline into an investment with multiple returns.
Webhooks and plugins for outbound events
When the flow is reversed — D365 needs to notify an external system — native webhooks allow publishing real-time events to any HTTP endpoint. A change in an order, an inventory update, or a customer modification automatically triggers a call to the receiving system, completing the data integration cycle without manual intervention.
Dynamics 365 plugins allow transformation logic before the event is sent out. This event-driven outbound pattern is the one that best eliminates the need for periodic polling — and with it, the greatest source of latency in legacy data integration architectures.
Dual-write for Finance & Operations scenarios
For companies operating both Dynamics 365 Finance & Operations and Customer Engagement applications, dual-write offers near-real-time bidirectional synchronization between both layers without additional code. Its use should be limited to that specific data integration scenario: forcing it as a bridge to external systems adds complexity without real benefit.
Comparison table: the three integration patterns
This matrix summarizes the key variables for choosing the right data integration pattern for your context. The decision is not primarily technical — it is a business decision: what latency the process can tolerate, what volume it handles, and what capacity the team has to maintain the solution.
| Pattern | Latency | Volume | Requires API in legacy? | Relative cost | Maintenance complexity |
|---|---|---|---|---|---|
| Direct API with adapter | Minimal (<1 s) | Low-medium | Yes (REST or SOAP) | Low | Medium (direct coupling) |
| Middleware (Logic Apps / Power Automate) | 1 s – 15 min | Medium-high | Optional (pre-built connectors) | Medium | Low (visual orchestration) |
| Change Data Capture (CDC) | Near real (<60 s) | High | No (reads DB log) | Medium-high | High (requires DB access) |
The three patterns that work in production
Choosing the right data integration pattern depends on three variables: required latency, record volume, and legacy system capabilities. There is no universal pattern — there is the right one for each case.
Pattern 1: Direct API with adapter
When the legacy system can expose or consume a REST or SOAP API, the cleanest solution for data integration is a lightweight adapter that translates the legacy contract into Dynamics 365’s OData format. There is no additional intermediary, latency is minimal, and control is total.
The risk is coupling: if the legacy system changes its contract, the adapter needs updating. That is why this data integration approach works best when the legacy system is stable or is under the internal team’s control.
Pattern 2: Middleware with Azure Logic Apps or Power Automate
This is the most common pattern in medium-sized data integration implementations. Azure Logic Apps acts as the orchestrator: it receives events from D365 or the legacy system, applies transformations, handles retries, and routes to the correct destination. Power Automate covers lower-volume cases with a more accessible learning curve.
The main advantage is operational visibility: every execution is logged, errors are alerted, and retries are configurable. Additionally, Logic Apps includes hundreds of pre-built connectors, which reduces development time when the legacy system is SAP, Oracle, or any platform with an available connector. This visibility is especially valuable in data integration projects with multiple systems.
For scenarios where transaction volume is high or the legacy system’s availability is not guaranteed, Azure Service Bus is added as an asynchronous buffer. Messages are queued, D365 consumes them at its own pace, and no transaction is lost even if one of the systems is temporarily unavailable. This asynchronous pattern is fundamental in data integrations with high-load systems.
Pattern 3: Change Data Capture (CDC) for legacy databases
When the legacy system has no API — a frequent scenario with proprietary ERPs or old SQL databases in LATAM — Change Data Capture detects changes directly in the transaction log without needing to modify the source system. This approach enables non-intrusive data integration on systems that cannot be modified.
Tools such as Azure Data Factory in incremental mode or specialized CDC connectors read changes in near real time and send them to Dynamics 365 through the Web API. This pattern is the one that comes closest to real-time synchronization without touching the legacy system’s code — a critical advantage when that system has no active support. For many data integration projects in LATAM, CDC is the only technically viable option.
Real case: retail in Mexico with CDC and Service Bus
A retail sector client in Mexico was operating with a proprietary WMS of more than twelve years and Dynamics 365 Sales as its CRM. Stock availability synchronization between both systems was done through an overnight ETL process: the sales team was working with data up to eight hours old, which generated sales commitments on already depleted stock. The absence of modern data integration was the main bottleneck for the business.
The architecture we implemented combined CDC on the WMS’s SQL database with Azure Service Bus as a buffer and the Dynamics 365 OData Web API as the destination. This data integration made it possible to completely eliminate the overnight ETL. The result: synchronization latency dropped from eight hours to less than 45 seconds, without modifying a single line of WMS code.
The operational impact was immediate: stock discrepancies in confirmed orders fell by 73% in the first month. The sales team gained real-time visibility into regional availability, and the logistics area reduced the time spent on manual reconciliations from four hours a day to less than twenty minutes. The decisive factor was not the technology — it was defining the system of record before writing a single line of configuration. In data integration projects, that prior definition makes the difference between success and rework.
Dynamics 365 middleware: when you need a dedicated integration layer
When the ecosystem exceeds two or three connected systems, point-to-point architecture becomes a problem. Each new direct connection adds a fragile dependency that someone will have to maintain. Data integration between multiple systems demands a centralized layer that eliminates that fragmentation.
A Dynamics 365 middleware centralizes flow logic: it transforms formats, routes messages, manages errors, and provides a single monitoring point for the entire data integration ecosystem. Maintaining seven direct pipelines costs more than maintaining a well-designed middleware layer with seven connectors.
In the Microsoft ecosystem, the combination of Azure API Management + Azure Logic Apps + Service Bus covers most enterprise data integration scenarios. API Management adds governance, throttling, and security over the APIs exposed by D365; Logic Apps orchestrates the flows; Service Bus guarantees message delivery.
Third-party iPaaS: MuleSoft, Boomi, and Jitterbit versus the Microsoft stack
The Microsoft stack is not the only option. Many teams in LATAM come to a Dynamics 365 data integration project having already invested in independent iPaaS platforms — MuleSoft, Boomi, or Jitterbit — and the real question is not which is better in the abstract, but when it makes sense to stick with what you already have.
When third-party iPaaS platforms are the right choice
MuleSoft Anypoint Platform is the most robust option for data integration when the systems ecosystem is heterogeneous and a team with Mule experience already exists. Its API-led connectivity model fits well in organizations with dozens of connected systems. The licensing cost is high (typically from 50,000 USD per year), but it is justified when the alternative is building custom connectors for each system.
Dell Boomi stands out for its ease of configuration and its low-code model, comparable to Logic Apps but with greater cloud provider independence. In the data integration space, its weak point compared to Logic Apps is the depth of native connectors for the Microsoft stack: integration with Dataverse and D365 works, but without the optimization offered by Microsoft’s native connector.
Jitterbit occupies an intermediate space in the data integration market: more accessible in price than MuleSoft, with pre-built connectors for Dynamics 365 and a focus oriented toward ERP-CRM integrations.
Decision criteria: native Microsoft or independent iPaaS?
The answer depends on four factors. First, the existing ecosystem: if 80% of your systems are Microsoft, the native stack reduces friction and cost in data integration. Second, team maturity: Logic Apps has a low learning curve for teams already on Azure; MuleSoft requires specialized profiles. Third, the licensing model: Logic Apps bills per execution, while third-party iPaaS platforms typically have higher fixed costs. Fourth, vendor lock-in: if the strategy is multicloud, a neutral iPaaS is a valid hedge for any data integration project.
In practice, what we most commonly see in LATAM is a hybrid scenario: Logic Apps for data integration flows within the Microsoft ecosystem and a third-party iPaaS for connections with complex external systems.
Real costs: what to budget for each pattern
These are the reference figures we use in medium-sized data integration projects in LATAM, based on published Azure prices as of 2024.
Azure Logic Apps
Logic Apps bills primarily by action and connector executions. In the standard consumption plan, each action costs approximately 0.000025 USD. A typical bidirectional synchronization flow — and therefore a data integration flow — can consume between 8 and 15 actions per execution. With 100,000 monthly synchronizations, the Logic Apps cost falls between 20 and 40 USD per month on the consumption plan. Premium connectors add a fixed cost of 1 USD per connection per month.
Azure Service Bus
Service Bus bills by messaging operations. At the Standard tier, the price is 0.05 USD per million operations. For an asynchronous buffer scenario with 5 million monthly messages in a data integration flow, the cost is approximately 0.25 USD per month in pure messaging. Most medium-sized projects in LATAM operate at the Standard tier without needing Premium.
Azure Data Factory (CDC and pipelines)
Data Factory bills by pipeline runs, orchestration activities, and data integration units (DIU). Each pipeline run costs 1 USD per 1,000 executions. An incremental capture pipeline on a SQL database with 500,000 daily rows can cost between 15 and 50 USD per month depending on execution frequency. Data integration units are the most variable cost component in intensive workloads.
Overall, a complete architecture with Logic Apps + Service Bus + Data Factory for a medium data integration scenario in LATAM can be budgeted at between 200 and 500 USD/month in Azure infrastructure costs, not counting Dynamics 365 licenses or development costs.
Progressive migration: how to coexist with the legacy ETL while building the new pipeline
The most common scenario in real projects is not “we shut down the ETL and turn on the new pipeline.” It is: the legacy ETL keeps running in production while we build the new data integration flow in parallel, and we need a clear criterion for the cutover.
The parallel pipeline strategy
The approach we apply at KCP Dynamics is to build the new data integration pipeline in shadow mode: the new flow processes the same events as the legacy ETL, but writes to a separate staging environment. For two to four weeks, the results of both systems are compared record by record. When the discrepancy rate falls below the agreed threshold — typically less than 0.1% — the cutover is activated.
This model has three advantages. First, the risk of data loss is almost zero: the legacy ETL remains the system of record until the new data integration pipeline demonstrates parity. Second, the team gains confidence in the new architecture with real data. Third, field mapping errors appear in staging, not in production.
Cutover criteria
The criteria we recommend documenting before starting the progressive data integration migration are: discrepancy rate below the agreed threshold, load test passed with volume equivalent to the production peak, rollback runbook validated by the operations team, and maintenance window agreed with the business for the definitive change. Once the new pipeline is activated, the legacy ETL is kept in monitor mode for at least two additional weeks before being permanently deactivated.
Security and compliance in the integration layer
The conversation about how to connect systems usually ends when the flow works. That is the moment when the conversation about how to protect it should begin. In LATAM, data protection regulations are tightening: the LGPD in Brazil, the Habeas Data Law in Colombia, and their equivalents in Mexico and Argentina impose concrete requirements on the handling of personal data in transit. Any data integration architecture must address these regulations from the initial design.
Every connection to the Dynamics 365 Web API must be authenticated via OAuth 2.0 with Azure Active Directory. The recommended pattern for server-to-server integrations is the client credentials flow, which eliminates dependency on individual user credentials. Never use user credentials in an automated pipeline — it is the most common failure vector when someone changes their password, and also one of the greatest security risks in data integration projects.
In Azure API Management, configure throttling policies per subscription to respect the documented Dataverse API limits: 6,000 requests per minute per organization at the standard tier.
Encryption in transit and at rest
All data integration traffic between systems must travel over TLS 1.2 as a minimum. In environments where the legacy system cannot negotiate modern TLS, the middleware acts as an SSL terminator. Never expose integration endpoints without encryption, even if they are internal to the corporate network.
For particularly sensitive data, consider field-level encryption before the data enters the data integration pipeline. Azure Key Vault centralizes key and secret management, eliminating hardcoded credentials in configurations.
LATAM compliance: what the pipeline must document
Privacy regulations in LATAM do not only affect storage — they affect transit. Any data integration pipeline that moves personal data between systems must have documented: what data travels, through which channels, with what encryption, and for how long logs are retained.
In practice, this means that Azure Logic Apps logs containing personal data must have retention policies configured and, in some cases, masking of sensitive fields. Compliant data integration is not improvised: compliance is not added at the end of the project — it is designed into the architecture.
Native connectors vs. custom connectors: where the line is
Dynamics 365 includes native connectors for the Microsoft ecosystem and for common platforms such as SAP, Salesforce, or Workday. They are the right starting point for any data integration project: they reduce implementation time and initial technical risk. But they have limits worth knowing.
Native connectors fail silently more frequently than well-built custom solutions. For proprietary legacy systems requiring critical data integration, a custom connector on the D365 Web API offers more control and better long-term traceability.
The right decision is not “native vs. custom” as a general principle. It is: what level of operational control do I need over this specific data integration pipeline? If a failure in that connection stops a critical business process, invest in a custom solution with explicit error handling.
Real-time synchronization: what it really means and what it does not
The term “real time” is used too loosely in demos. Before defining the data integration architecture, it is worth agreeing with the business on what latency is acceptable for each flow. Not all data needs real-time synchronization — and forcing it where it is not necessary adds complexity and cost without benefit.
A practical guide for classifying data integration flows by required latency:
- Strict real time (<1 second): stock availability at point of sale, credit approvals. Requires webhooks or CDC with streaming processing. Data integration in this range is the most technically demanding.
- Near real time (1-60 seconds): order updates between CRM and ERP. Azure Service Bus with reactive consumers covers this data integration range.
- Near real-time (1-15 minutes): customer master synchronization, price updates. Logic Apps with high-frequency scheduled triggers resolve this data integration scenario.
- Controlled batch (>15 minutes): accounting consolidation, closing reports. Azure Data Factory in incremental mode. This data integration model remains valid for non-critical flows.
Classifying each data integration flow before designing the architecture reduces technical over-engineering — one of the factors that most inflates cost without delivering real value.
Common mistakes in Dynamics 365 integration projects in LATAM
In real projects with clients in manufacturing, retail, and financial services, data integration failure patterns repeat themselves. Knowing them in advance is the difference between a project that goes into production on schedule and one that is six months late.
Ignoring data governance from the start
Data integration is not just about moving records from A to B. It is about deciding who is the system of record for each entity. If both the legacy ERP and Dynamics 365 can modify the customer master, you need a conflict resolution policy before writing a single line of code. Without that policy, real-time synchronization creates data inconsistencies that are harder to resolve than the original problem.
Not planning error handling
A data integration pipeline that works 95% of the time is a broken pipeline. The 5% of failures without explicit handling becomes lost data, duplicate records, and manual reconciliations that consume more time than the process that was meant to be automated. Every data integration flow needs: an error log, retry logic with exponential backoff, and an alert to the responsible team.
Underestimating the impact of production volume
Test environments rarely replicate the volume, concurrency, and timing patterns of the production system. A data integration architecture that responds in 200ms with 100 records can become saturated with 50,000. The Dynamics 365 API throttling has documented limits — ignoring them in the design creates bottlenecks that only appear when the business already depends on the system.
How to assess whether your architecture is ready for production
Before closing a project connecting Dynamics 365 with legacy systems, there is a set of criteria that at KCP Dynamics we use as a data integration maturity checklist. The maturity of an architecture is not measured only by whether it works, but by whether it can be maintained and recovered when something fails.
- Full traceability: every message has a unique ID traceable end to end, from the source system to Dynamics 365. Without traceability, data integration cannot be audited.
- Documented error handling: there is a runbook that defines what to do when each type of data integration flow fails, who receives the alert, and within what timeframe.
- Load tests with real data: the system has been validated with volumes equivalent to production peaks.
- System of record defined: for each critical entity, it is documented which system holds the authoritative version of the data in the data integration flow.
- Active monitoring: there is a dashboard showing the status of each data integration flow in real time, with alerts configured for latency and error rate.
- Rollback plan: if the pipeline fails in production, there is a documented procedure to revert without loss of records or corruption of integrated data.
- Documented compliance: data integration flows that move personal data have the legal basis, applied encryption, and log retention policy on record.
If any of these points is blank, the data integration architecture is not ready for production — even if it works in the test environment. The difference between a successful demo and a system that operates reliably for three years lies exactly in these details.
[CTA:diagnostico-integracion]
Frequently asked questions
Can I connect Dynamics 365 with a legacy system that has no API?
Yes. When the legacy system does not expose an API, the most effective data integration pattern is Change Data Capture (CDC): it detects changes directly in the database transaction log without modifying the source system. Tools such as Azure Data Factory in incremental mode allow capturing those changes and sending them to Dynamics 365 in near real time. This is the approach we apply when the legacy system has no active support or the vendor no longer exists.
What is the difference between using Power Automate and Azure Logic Apps to integrate Dynamics 365?
Power Automate is oriented toward business users and lower-volume flows, with a more accessible interface and premium connectors available without code. Azure Logic Apps is designed for enterprise data integration orchestration: greater control over execution, better error handling, support for asynchronous patterns with Service Bus, and more scaling options. For critical integrations with legacy systems in production, Logic Apps offers the necessary robustness. Power Automate is the right entry point for secondary flows or teams with lower technical maturity.
What is dual-write and when should I use it?
Dual-write is Microsoft’s native mechanism for near-real-time bidirectional synchronization between Dynamics 365 Finance & Operations and Customer Engagement applications (Sales, Service). It is the right data integration option when you operate both D365 layers and need customer, product, or order data to be synchronized without additional development. It is not designed to connect Dynamics 365 with external systems — using it as a bridge to legacy ERPs adds complexity without real advantage.
How do I avoid duplicating data when two systems can modify the same record?
By defining the system of record for each entity before designing the data integration. That means only one system has authority to create or modify each type of data — the other receives the update as a consumer. If both systems need write capability, you need an explicit conflict resolution policy: for example, “last writer wins” or “D365 takes priority over the legacy system for customer data.” Without that documented policy, real-time data integration generates inconsistencies that are hard to trace.
How long does a Dynamics 365 integration project with legacy systems take?
It depends on the number of flows, the complexity of the legacy system, and the team’s maturity. A point data integration with a system that exposes an API can be in production in four to six weeks. A complete data integration project with multiple systems, CDC on databases without an API, and a dedicated middleware layer can take three to six months. The factor that most impacts the timeline is not development — it is defining business rules: which data is authoritative, what happens when it fails, who approves schema changes.