04. CDE Integration: Integrating CDEs Without Rebuilding Your Data
CDE integration is the work of connecting two or more Common Data Environments (CDEs) so that models, documents and metadata move between them without anyone downloading, renaming and re-uploading files. The platforms stay where they are. Each party keeps working in the system it already uses, and a mapping layer between the two handles the translation.
Most organisations did not design the estate they now have to connect. A client mandates one platform, a joint venture partner brings a second, and the design supply chain arrives with a third. Integrating CDEs starts from that mix.
This article covers:
What CDE integration means in practice
Why integration should not require any party to restructure its data
The four routes to integrating CDEs
The cost, setup time and maintenance owner of each route
The case where a native vendor connector is the right answer
What to check before choosing a route
What is CDE integration?
CDE integration is an ongoing connection rather than a single transfer. Files, version history and metadata move on a schedule or on an event, in one direction or in both, for as long as the connection runs. A migration moves a record once and then finishes. Migration or Sync? Knowing Which One Your Project Actually Needs sets out where that line sits.
Every working integration has three parts: authentication to each platform, a map between the two folder structures, and a map between the two metadata schemas. The third part carries most of the effort, because Architecture, Engineering, Construction and Operations (AECO) platforms model attributes such as revision, suitability, discipline and classification in different ways.
The number of platforms in play rules out doing this by hand. Deloitte and Autodesk found in their 2025 State of Digital Adoption research that construction businesses across Asia Pacific use a median of 11 separate data environments, and that streamlining them could return 10.5 hours per week.
What integrating CDEs should not require of the parties
Integration proposals often open with a plan to standardise. Someone suggests a common folder taxonomy, a single naming convention, or one metadata schema that every party will adopt before any data moves.
On a real project no party has the authority to require that of the others. A subcontractor's folder taxonomy is tied to its quality system, its document numbering and its audit history, and its metadata schema is limited to the fields its CDE licence exposes. Asking it to rename its files so that another organisation's connection works is asking it to break its own record.
The mapping has to absorb the difference instead of removing it. Structure A stays as structure A, structure B stays as structure B, and the map holds the translation: this folder to that folder, this discipline code to that discipline code, this suitability value to that status field. Where a field has no counterpart on the other side, the map decides whether to derive a value, apply a documented default, or hold the file back. Techture Global reported in 2024 that 30 per cent of AEC professionals experience project delays caused by file format conflicts and 40 per cent spend extra time manually converting files between systems.
Native connectors supplied with the platform
Platform vendors ship connectors that work outward from their own ecosystem, and they are good at the job they were built for. The cost is low or bundled into a licence you already hold, setup runs to hours, and the vendor maintains the connector, so an API change is handled on their side.
A native connector is genuinely the right answer for an organisation running two platforms from one vendor. A shared data model and no third party CDE in prospect means the connector supplied with the licence will do the job. Moving information between two Autodesk environments inside one tenancy is that case, and a neutral integration layer would add cost without adding capability.
The limit appears when a platform from outside the vendor's family joins the project. Native connectors bring data into an ecosystem or push it out rather than treating a competitor's CDE as a peer. Coverage across that boundary is partial, metadata fidelity is the weakest part of it, and the roadmap belongs to the vendor.
General purpose integration tools and iPaaS
General purpose integration platforms are mature, well documented and inexpensive to start with. A workflow specialist can build a first flow in an afternoon, and for moving a record between a customer system and a finance system they work well.
AECO data carries obligations a generic record does not. A file crossing between CDEs has to arrive with its version lineage, revision code, suitability state and evidence of approval, and a large infrastructure project moves 50 to several thousand models and documents a week. Per task pricing that looks trivial at ten records a day becomes a significant line item at that throughput, and the domain logic still has to be built by hand inside a tool with no concept of a transmittal. Why General Integration Tools Like Workato and Zapier Fall Short of AECO Requirements covers the detail.
Custom development against vendor APIs
Custom development gives an organisation exactly what it specifies. Where an internal system has no commercial connector, or a security posture rules out third party processing, building against the vendor APIs is a legitimate choice.
The build is the smaller half of the commitment. Every connected platform ships API changes, deprecates endpoints, rotates authentication methods and revises rate limits on its own schedule, and each event becomes unplanned work for your developers. The mapping engine, retry and conflict handling, audit logging and monitoring sit in the same scope. Why Custom CDE Integration Development Costs More Than You Think works through what that adds up to.
Purpose-built AECO integration platforms
A purpose-built platform sits between the CDEs as a neutral party and already understands what a version, a revision, a suitability code and a transmittal are. Document control staff configure it rather than developers, and the vendor maintains the connectors to each platform.
CDE Sync™ is built on that model, with no-code wizard configuration across 21 supported vendor integrations and a first sync typically running 15 to 30 minutes after setup begins. What an organisation takes on in exchange is a subscription and a dependency on a third party for connector maintenance.
Most of this work is still done by hand. On JBKnowledge Construction Technology Report data cited by Autodesk, 49 per cent of construction professionals transfer data manually, 45 per cent rely on spreadsheets, and only 6 per cent of contractors report having all their applications seamlessly integrated.
The four CDE integration routes compared
What to check before choosing a CDE integration route
How many vendors are in the estate. One vendor with two platforms points to a native connector. Three or more vendors, with a supply chain that changes between packages, points to a neutral layer.
What has to survive the crossing. List the attributes that carry contractual meaning, including revision, suitability, originator and approval evidence. A route that cannot carry them is not a candidate.
What the throughput will be at peak. Price the route at the busiest week of the programme rather than at pilot volumes, particularly where pricing is per task or per record.
Who maintains the connection in three years. Name the team or the vendor. If the answer is one developer, the connection is a personnel risk.
What happens when a platform changes its API. Establish whether that lands on your team as unplanned work or on a vendor under a support agreement.
A wider view of the products in this category sits in CDE Integration Comparison: The Complete Guide for AECO Project Teams.
Does CDE integration mean everyone has to use the same folder structure?
No. A properly built integration maps one structure onto another and leaves both parties working as they already work. Requiring a common taxonomy across organisations only succeeds where one party can impose it, and on a joint venture or a multi-tier supply chain that is uncommon. The mapping layer carries the difference.
When is a native CDE connector the right choice?
When the estate is two platforms from a single vendor with a shared data model and no third party CDE expected. The connector supplied with the licence costs little, the vendor maintains it, and a neutral integration layer would be solving a problem the organisation does not have.
How long does integrating CDEs take?
It depends on the route. A native connector can be running in hours. A purpose-built platform can produce a first sync in 15 to 30 minutes once the mapping decisions are made, and the mapping workshop beforehand takes the real time. Custom development runs to months before the first file moves.
CDE Sync keeps every party's folder taxonomy and metadata schema in place and puts the translation in the mapping layer, with no-code configuration and version history preserved across the connection. Book a demo to see it run against your own platforms, and bring a real folder tree and a real field list.