For most of the 2010s and early 2020s, the modern data stack was defined by independent specialists: one vendor for ingestion connectors, another for transformation, another for event streaming, another for data quality and so on. Data teams assembled best-of-breed tools around a cloud warehouse or lakehouse. In 2025 and 2026, that landscape changed quickly. Several of the best-known independents were merged into one another or acquired by much larger platform companies.
If your integration architecture depends on any of these products, consolidation is not just industry news. It can change pricing, roadmaps, support, open-source commitments and the strategic direction of tools your pipelines rely on every day. This article summarizes what happened, explains why, and offers a practical framework for managing vendor risk in your data integration stack.
What Happened: The Key Deals
- Fivetran and dbt Labs. Announced in October 2025 as an all-stock merger and completed on June 1, 2026, according to the companies’ announcement and TechTarget’s coverage. The combined company operates as Fivetran + dbt Labs, with George Fraser as CEO and Tristan Handy as president, and says it supports more than 100,000 data teams. At completion it announced plans to open source the dbt Fusion engine runtime as dbt Core v2.0 (alpha) under the Apache 2.0 license, along with dbt State (a caching layer that rebuilds only changed models), dbt Wizard (AI-assisted authoring) and Agents Schema, an open-source convention for a shared context layer for AI agents. TechTarget noted that several of these were still in testing at launch.
- IBM and Confluent. IBM announced in December 2025 that it would acquire Confluent, the company founded by the original creators of Apache Kafka, for $31 per share, about $11 billion. Techzine reported the deal complete in March 2026, with integrations that stream live events into IBM watsonx.data and connect Confluent with IBM Z, IBM MQ and webMethods Hybrid Integration.
- Salesforce and Informatica. Salesforce completed its acquisition of Informatica in late 2025, bringing one of the largest enterprise data integration and data management portfolios into a CRM and AI platform company.
- SAP and Dremio. TechTarget’s coverage of the Fivetran–dbt merger also cites SAP’s acquisition of Dremio, the Iceberg-focused lakehouse query engine company, as part of the same consolidation pattern.
Why Consolidation Is Happening Now
Several forces are pushing the market in the same direction.
- AI needs end-to-end data supply chains. Vendors argue that AI agents need trusted, fresh, well-modeled data with clear semantics. Owning ingestion, transformation, streaming and metadata together lets a vendor sell that whole supply chain.
- Platform gravity. Cloud providers and data platforms such as Databricks, Snowflake and Microsoft Fabric keep adding native ingestion, CDC, transformation and orchestration. Independent tools face pressure to become platforms themselves or join one.
- Scale economics. Analysts quoted by TechTarget suggested that reaching sufficient scale, possibly for a public listing, was part of the rationale for the Fivetran–dbt merger.
- Buyer fatigue with tool sprawl. Many organizations want fewer contracts, fewer integrations between tools and a smaller security review surface.
What It Means for Data Teams
Potential upsides
- Tighter integration between ingestion, transformation and metadata, with fewer brittle hand-offs between tools.
- Larger vendors with more resources for security certifications, global support and enterprise features.
- Investment in AI capabilities, such as AI-assisted modeling and context layers for agents, that small independents might not fund.
- Possible open-source releases, such as the stated plan to open source the dbt Fusion runtime as dbt Core v2.0.
Potential risks
- Pricing changes. Bundling can bring discounts, but also repackaging, minimum commitments or consumption models that raise costs for some usage patterns. TechTarget quoted an analyst noting Fivetran’s reputation for aggressive consumption-based pricing.
- Roadmap shifts. Acquirers may prioritize integration with their own platforms over neutrality across clouds and engines. Features that serve competing platforms can slow down.
- Open-source trust. Analysts in the same coverage stressed that keeping the dbt open-source community’s trust is a key challenge. Licensing or governance changes to widely used open-source projects have precedent in the industry.
- Engineering distraction. Merged companies often spend a period integrating products, which can slow innovation and support responsiveness.
- Contract and support transitions. Renewal terms, support channels and account teams can change during integration.
Consolidation does not make your current tools bad overnight. It does make vendor neutrality a property you must design for, rather than one you can assume.
Layer by Layer: Where the Impact Lands
Consolidation affects each layer of the integration stack differently. Thinking layer by layer helps prioritize attention.
Batch ingestion and managed connectors
Managed connector services remain valuable for long-tail SaaS sources where building and maintaining your own connectors is wasteful. The main risks here are pricing and bundling. Because connectors are configuration rather than code, switching is usually feasible, but it requires re-validating each source, backfilling history and checking that schemas and naming conventions match what downstream models expect.
Transformation and modeling
This is where the most business knowledge lives. SQL models, tests, documentation and metric definitions represent years of accumulated decisions. The safest posture is to keep this layer in open, version-controlled code that can run on more than one engine and more than one tool, and to adopt proprietary extensions consciously, with a clear understanding of what would need rewriting.
Event streaming
Kafka’s protocol is widely implemented by multiple vendors and cloud services, which gives streaming users unusual portability at the protocol level. The less portable parts are managed connectors, stream processing jobs, governance features and schema registries tied to one provider. Inventory these specifically if your streaming platform has changed ownership.
Enterprise integration and data management suites
Large suites that combine integration, master data, quality and cataloging are typically deeply embedded and expensive to replace. When such a suite moves into a larger platform company, the questions are about long-term neutrality across clouds and applications, and about how the suite will be packaged and priced alongside the acquirer’s other products.
A Framework for Managing Integration Vendor Risk
The goal is not to avoid commercial tools. It is to make sure the critical assets in your integration stack remain portable if a vendor’s direction changes.
1. Map your dependency surface
List every integration product you use with its role (ingestion, CDC, streaming, transformation, orchestration, reverse ETL, data quality), owner, number of pipelines, data volume, contract terms and renewal date. Identify which products were affected by recent deals and which are platform-native features of your warehouse or lakehouse.
2. Classify assets by portability
- Highly portable: SQL transformation code in Git, data in open table formats, Kafka topics using standard protocols and schemas in open formats such as Avro, Protobuf or JSON Schema.
- Moderately portable: connector configurations, orchestration definitions and data quality rules that can be exported and recreated with effort.
- Low portability: logic built only in proprietary visual tools, vendor-specific semantic layers without export, and managed connectors with custom transformations embedded in the tool.
3. Protect the high-value assets
Your transformation logic, data models, metric definitions and schemas encode years of business knowledge. Keep them in version control in portable forms. For dbt users, that means keeping projects compatible with the open-source engine where possible and being deliberate about adopting features available only in commercial tiers.
4. Standardize interfaces, not just tools
Adopt open standards at the boundaries: Apache Iceberg or Delta Lake for analytical storage, the Kafka protocol for event streaming, OpenLineage for lineage, Open Data Contract Standard for data contracts and standard SQL for transformations. When interfaces are open, replacing a tool becomes a contained project rather than a re-platforming.
5. Negotiate with consolidation in mind
- Seek price protection and caps on increases at renewal.
- Clarify data export rights for configurations, metadata and logs.
- Confirm support levels and named contacts through integration periods.
- Avoid long commitments that assume a roadmap the vendor has not contractually promised.
6. Keep an exit option warm
For each critical tool, identify at least one realistic alternative, whether a platform-native capability, another commercial product or an open-source option, and run a small proof of concept every year or two. Teams that have done this recently negotiate from strength.
Decision Guide: Stay, Expand or Diversify?
When a vendor you depend on is part of a deal, use these questions to decide how to respond.
- Does the combined roadmap align with your target architecture? If you are standardizing on the acquirer’s platform, consolidation may be a benefit. If not, watch for neutrality erosion.
- Is pricing predictable for your usage pattern? Model renewal costs under realistic growth, including new bundles.
- How portable is what you have built? High portability lowers the urgency of any change.
- Are open-source commitments concrete? Look for licenses, governance arrangements and release cadence, not just announcements.
- What does your platform already provide? Native CDC, ingestion and transformation features may now cover needs that once required separate tools.
Often the answer is a mix: stay with a consolidated vendor for workloads where it excels, move simple workloads to platform-native features and keep critical logic portable regardless.
A 90-Day Action Plan
- Weeks 1–3: build the dependency map and portability classification for every integration tool, and list renewal dates for the next 18 months.
- Weeks 4–6: move the highest-risk low-portability assets, such as logic embedded in tools, into version-controlled code; export metadata and configurations.
- Weeks 7–9: run a focused proof of concept of one alternative for your most critical or most expensive tool, measuring effort, cost and gaps.
- Weeks 10–12: bring the findings to procurement and leadership, set negotiation priorities for upcoming renewals and agree a review cadence for vendor news.
Pitfalls to Avoid
- Reacting to headlines. Rushed migrations away from a newly merged vendor can cost more than any plausible price increase. Decide on evidence.
- Ignoring platform-native options. Warehouse and lakehouse platforms now include ingestion, CDC and transformation capabilities that may cover simpler workloads well.
- Equating open source with zero risk. Open-source projects also depend on vendor stewardship; check governance, licensing and contributor diversity.
- Leaving metadata behind. Lineage, tests, documentation and semantic definitions are as important to portability as the data and code.
Worked Example (Hypothetical)
A hypothetical North American software company runs about 300 managed ingestion connectors into a cloud warehouse, a dbt project with roughly 1,500 models, a managed Kafka service for product events and a separate reverse-ETL tool. After the 2026 deals, the CFO asks whether the stack is at risk.
The data team maps dependencies and finds that its dbt project is portable and already in Git, Kafka topics use standard protocols with Avro schemas in a registry, and warehouse data is increasingly stored in Iceberg tables. Lower portability sits in a dozen connectors with custom transformations configured inside the ingestion tool and in metric definitions maintained only in a commercial semantic layer. The team moves those connector transformations into dbt, exports metric definitions into version-controlled files, and negotiates a renewal with price caps. It also pilots the warehouse’s native CDC for its two largest databases to understand alternatives. The result is not a migration but a stack that can change course if needed.
Outlook: 2027–2030
Expect further consolidation as remaining independents in data quality, observability, catalogs and orchestration face the same pressures. Expect platforms to absorb more integration functionality natively and vendors to compete on AI-ready context, governance and cost. At the same time, open standards such as Iceberg, Kafka, OpenLineage and open data contract specifications will matter more, because they are what allow customers to switch components as the market reshapes itself.
For data leaders, the practical implication is to revisit integration vendor strategy at least annually, tie each review to upcoming renewals, and treat portability as an explicit architecture requirement with owners and metrics, just like security or reliability.
Conclusion
The 2025–2026 wave of deals has turned the data integration market from a field of independent specialists into a contest among a few large platforms. That can bring better integration and more investment in AI capabilities, but it also raises the stakes on pricing, roadmaps and openness. The practical response is not panic but design: keep logic and data in portable forms, standardize on open interfaces, negotiate with consolidation in mind and keep a realistic alternative ready for every critical tool.
How Hanoi Technology Can Help
Hanoi Technology assesses integration stack risk and builds portable ingestion, streaming and transformation pipelines through projects, dedicated teams or managed services.