Service · Software development

Data integration consulting for fragmented data landscapes.

We advise on and build data integrations. From APIs and ETL pipelines to iPaaS choices, data warehouses and streaming architectures. Pragmatic advice, followed by working connections, without vendor dogma.

Arrange an introductory call See our work

Data integration is much broader than API connections.

Many parties sell "integration" as if it simply means connecting two systems via a REST API. That is one flavour of data integration, but certainly not the only one. A mature integration approach covers synchronous API connections for real-time use cases, batch ETL for nightly data warehouse loads, streaming architectures for data in motion, file-based drops via SFTP for partners who cannot do otherwise, and iPaaS platforms that bring all these patterns together under one dashboard.

Above that sits the strategic level: which data lives where, what the source of truth is, which quality issues block consolidation, and which master data management approach suits the organisation. We guide that strategic level and also build the execution. Read our approach to smart API integrations if you are specifically looking for the tactical side: real-time connections between SaaS systems.

What sets us apart from pure consultancy firms: we do not hand you a PowerPoint that you then have to implement yourself. We write the architecture and build the pipelines, configure the warehouse, model the dbt layer, or select an iPaaS platform and set up the first flows. No black-box handover, no "advice delivered, good luck".

What data integration consulting involves in practice.

Discovery
Mapping sources, targets and data flows
Architecture
Choosing per use case: API, ETL, streaming, iPaaS
Implementation
Pipelines, connections or platform configuration
Governance
Monitoring, data quality and ownership per flow

Three types of data integration projects.

Depending on where your organisation stands: fragmented with no overview, running on an iPaaS that has reached its limits, or ready for a serious data warehouse.

Engagement 01

Integration architecture & vendor selection

For organisations without a clear approach

You have ten SaaS tools that do not, or only partly, talk to each other. We map the landscape and choose the right pattern per use case (real-time API, nightly batch, event-driven streaming or file-based), and advise on build versus buy: do we build point-to-point connections, choose an iPaaS platform such as MuleSoft, Boomi, Workato or Azure Logic Apps, or build a custom middleware layer? An independent assessment based on data volumes, latency requirements, operational capacity and TCO. We do not represent any platform; our interest lies in the solution, not the licence.

Landscape auditPattern selectioniPaaS comparisonTCO analysis
Engagement 02

Custom integrations & middleware

For industry-specific flows that standard tools cannot handle

When iPaaS platforms reach their limits, for example with high volumes, industry-specific messaging protocols or complex transformation logic, we build custom integrations. Real-time connections between bespoke ERP systems, financial platforms, production MES, or foreign suppliers with idiosyncratic formats. Custom middleware with proper logging, retry mechanisms, idempotency and version management. Suited to organisations that have already considered an iPaaS platform and backed out over pricing or expressiveness.

Custom middlewareEvent-drivenIndustry protocolsIdempotent flows
Engagement 03

Data warehouse & analytics foundation

For those who want to become data-driven

You need proper reporting across the whole organisation, but your figures come from six different systems, each claiming to hold the truth. We build a data warehouse on Snowflake, BigQuery or Redshift, set up ETL pipelines from all sources, model the data with dbt, and lay the foundation for your KPI dashboards. This includes attention to data quality, master data management, historisation and governance. For some clients it also means a data lake on S3 or Delta Lake as a landing zone for raw data and machine learning use cases.

Snowflake / BigQuerydbt modellingData lakeMDM & quality

What you take away from an engagement.

No loose recommendations, but working integrations plus the documentation and runbooks needed to keep them running.

Integration blueprint

For each data flow, the choice of approach (API, ETL, streaming, file), justified by latency, volume and cost.

Working pipelines

Configured iPaaS flows, custom middleware or dbt models, in both production and staging.

Monitoring and alerting

Health checks, error alerting and data quality rules on critical flows.

Runbook & documentation

Who owns what, what to do when a failure occurs, and how to roll out a change.

Managed service (optional)

Monitoring, incident handling, further development and quarterly reviews of data quality.

When data integration consulting really makes a difference.

Four patterns we most often encounter in mid-market and larger organisations.

Fragmented SaaS landscape

Ten tools that don't talk to each other

Over the past few years you have bought standalone SaaS tools: CRM, marketing automation, helpdesk, e-commerce, ERP, HR. Each department works in its own system, nobody has the full picture, and manual Excel bridges just about hold things together.

Legacy replacement

From monolith to modern via an integration layer

You are replacing an old core system but cannot do it as a big bang. An integration layer between old and new makes a phased migration possible. See also our approach to enterprise software development, where this pattern often comes up.

Reporting pressure

CSRD, ESG or management reporting

You must report on matters whose data is spread across financial, operational and HR systems. Without a central warehouse, every report remains a manual exercise. We build the pipelines and data model so reporting becomes repeatable.

Multi-site

Groups with scattered administrations

Different subsidiaries, countries or sites each run on their own systems or versions. Consolidated insight is missing. We design an approach that preserves local autonomy while still steering the group on a single set of figures.

How we differ from pure data consultancies.

More firms call themselves data integration consultants than you might expect. Broadly, they fall into two camps. On one side are strategic advisory firms that deliver excellent slides on data strategy, governance frameworks and data maturity models, but do not build anything themselves. On the other side are implementation partners for one specific platform: a MuleSoft shop, a Boomi partner, or a Snowflake implementation firm. They have commercial incentives to sell their own tooling, even when it is not the best fit.

We deliberately sit in the middle. We have no platform partnerships on which we earn revenue or margin. Our profit comes purely from the engagement itself. That means we can advise honestly: for some clients an iPaaS is the right choice, for others point-to-point or custom middleware is. For one organisation Snowflake is overkill and PostgreSQL with good modelling will do; for another a data lakehouse on Databricks or Delta Lake is the answer.

Because we also build the pipelines ourselves, we know where the complexity hides in quotes and vendor claims. We can spot which "out-of-the-box" iPaaS connector in practice requires three weeks of custom work. We know which warehouse can genuinely handle which data volumes. Advice that comes out of hands-on implementation stays realistic, and that makes it sharper.

How a data integration project runs.

01Introduction→ 02Discovery→ 03Architecture→ 04Build & operate
First conversation

Introduction

Which systems, which pain points, which use cases. No obligation.

Workshops & interviews

Discovery

Source inventory, data volume measurement, quality check, ownership per data flow.

Document & decisions

Architecture choice

The right approach for each use case. Build versus buy, iPaaS shortlist, warehouse selection.

Sprints & ongoing

Build & operate

First flows live within a few sprints, then gradual expansion and management.

Approaches we often combine.

No organisation needs just one type of integration. In practice, we combine several patterns within each project. Real-time API integrations are the right fit where transactions must flow through immediately, such as a payment that needs to update an order status, or a lead that must land in the CRM straight away. Batch ETL suits situations where latency of a few hours is perfectly acceptable, such as overnight financial consolidation or loading a warehouse from operational systems.

Streaming and event-driven architectures (Kafka, RabbitMQ, Google Pub/Sub, AWS Kinesis) are the right choice when data in motion is essential: events that multiple consumers need to handle at once, or organisations looking to evolve towards a genuine event-driven architecture. File-based integrations via SFTP, EDI or CSV drops remain indispensable for partners, particularly in logistics, the financial sector and government, who simply cannot or will not work any other way.

At the strategic level, we advise on iPaaS platforms such as MuleSoft, Boomi, Workato and Azure Logic Apps: when they are worth their licence costs, and when they are not. We advise on API-first refactoring, in which a monolithic legacy application is gradually given a modern API layer, so that new applications and integrations connect through controlled endpoints. And we advise on master data management and data quality, because the most sophisticated pipeline solves nothing if the source systems use different customer numbers and product codes.

Technologies we work with.

No dogma about a single platform. We choose what fits each situation based on volume, latency, management capacity and cost.

iPaaS and middleware
MuleSoftBoomiWorkatoAzure Logic Appsn8nCustom middleware
Warehouse and lake
SnowflakeBigQueryRedshiftPostgreSQLDelta LakeS3 + Athenadbt
Streaming and messaging
KafkaRabbitMQGoogle Pub/SubAWS KinesisWebhooksEDI / SFTP

Frequently asked questions about data integration consulting.

What is the difference between API integration and data integration?
API integration is one of the patterns within data integration. An API integration is typically synchronous and real-time: system A requests something from system B and waits for a response. Data integration is a broader term that also covers batch ETL (overnight data loads), streaming (events via Kafka or Pub/Sub), file-based exchange (CSV, EDI or JSON via SFTP), and data warehousing (consolidating multiple sources in one place). Which pattern is the right choice depends on latency requirements, data volume and how many systems are involved. See also our separate page on smart API integrations for the tactical side.
Do you replace iPaaS platforms such as MuleSoft or Boomi?
No, and that would not be honest advice either. For many organisations, iPaaS platforms are an excellent choice: a standardised way to manage integrations, reusable connectors, audit trails and monitoring out of the box. We guide the choice between platforms, configure the flows and give independent advice on when iPaaS is the right investment and when it is not. We only build custom middleware where iPaaS platforms hit technical or commercial limits.
When do we choose iPaaS, and when custom middleware?
iPaaS suits organisations with many relatively standard connections between well-known SaaS systems, moderate data volumes, and a wish to place management with a dedicated integration development team. Custom middleware is a better fit for high-volume scenarios, sector-specific messaging protocols (EDI, Peppol, HL7), highly complex transformation logic, or organisations that cannot or do not want to bear iPaaS licence costs. We often combine both: iPaaS for the standard connections, custom where it is needed.
Which data warehouse should we choose: Snowflake, BigQuery or Redshift?
There is no universal answer. Snowflake offers the most cloud-agnostic experience and is strong with workloads involving many short-running queries. BigQuery integrates best within Google Cloud and excels in serverless and pay-per-query models. Redshift is best suited to AWS stacks and predictable workloads. For smaller organisations, a well-modelled PostgreSQL is sometimes sufficient, as a warehouse is not always necessary. The choice depends on your existing cloud stack, data volumes, query patterns and budget. We weigh these up independently; we earn nothing from any licence.
Real-time or batch: what is the right choice for us?
Real-time is more expensive, more complex and harder to manage. It is only the right choice when the business case justifies it: an order status that must update within seconds because customers would otherwise phone, fraud detection that cannot wait until midnight, or a personalised experience that must work at the moment of interaction. For many use cases, batch processing, such as nightly ETL, is simpler, more robust and cheaper. We advise on each flow separately and do not try to make everything real-time simply because it sounds "modern".
What determines the cost of a data integration project?
The number and complexity of source systems, the chosen architecture (iPaaS licence costs, warehouse costs, custom build effort), the data volumes, and the amount of data quality work required. It also depends on whether there are existing integrations we can reuse or whether we start from scratch. A bounded connection between two systems is a different conversation from an organisation-wide data platform foundation with dbt modelling. After the discovery phase, we provide a substantiated scope indication. We do not publish "from" prices on the website, as the range in practice is too wide to communicate honestly.
Do you combine consultancy with actual implementation?
Yes, that is a deliberate choice and the difference from pure consultancy firms. We do not only write the architecture and the roadmap; we also build the pipelines, configure the iPaaS platform, write the dbt models or set up the streaming architecture. This keeps our advice sharp, as we are directly confronted with the assumptions we make. For organisations that prefer an external party to do the build, we can also act purely as an adviser and vendor management partner, guiding a third party that carries out the implementation.
How long does such a project typically take?
A clearly defined discovery with an integration blueprint is a short engagement of a few weeks. We then deliver the first working integrations in a handful of sprints. A full data platform with a warehouse, modelling and multiple integration flows is a multi-sprint engagement with an ongoing management and further development phase. We don't make firm timeline promises before we understand the scope, as that would be irresponsible for both sides.
Do you work alongside our existing IT suppliers?
Almost always. We're not out to replace what already works. We often recommend making further use of existing iPaaS licences or data warehouse investments rather than replacing them. Working alongside your own team and existing suppliers is part of almost every engagement. We see our role as a sounding board and catalyst, not as the sole authority over your data landscape. For the wider strategic context, we often work as your digital transformation partner.

Talk to us about your data integration.

A no-obligation conversation of about half an hour. We listen to your situation (which systems, which pain points, which ambitions) and give you direction. Even if the outcome is that a different platform or partner is a better fit.

Schedule an introductory callEmail fabian.vandijk@appfront.nl

Related: Custom rental software development

A complementary angle on this theme can be found at applatenmaken.com: Custom data integration software development.

Edit content