Custom ETL and middleware engineering: we keep stock, price, order and customer data moving between your ERP, CRM, WMS and the systems your business runs on. Audit, pipeline, monitoring. Since 2010, on Magento, Sylius, Symfony and custom applications.

Let's talk about your data

Nobody buys their enterprise stack all at once. The ERP arrived when finance needed control, the CRM when sales expanded, the WMS when the warehouse scaled, and the storefront when online channels took off. Each was the right tool at the right time, and none of them were chosen for how well they would talk to each other.

That gap is where we step in. We build the data pipelines and middleware that keep your systems moving in sync at the precise rhythm each operational workflow requires, backed by robust error handling and reconciliation for when sources conflict.

No off-the-shelf connectors, no recurring subscription fees, and no rented middleware. Just custom engineering built directly against your architecture by experts who understand the nuances behind your data.

Systems exchanging data through a central integration layer Six systems connected by dashed lines to a central layer, with data moving along the connections.

Since 2010, Sutunam has designed, built and monitored data integrations across commerce platforms, enterprise systems and business intelligence stacks. Stock, price, product, order and customer data, moving at the frequency each type actually needs.

Before you read on

Two things worth knowing

Most of this market sells a subscription with proprietary connectors. We do not, and it changes what you are buying.

You own what we build

The code, the documentation, the mapping rules and the infrastructure configuration are yours. There is no proprietary connector you keep paying to use, no runtime licence, and no clause that makes leaving expensive.

If your team wants to take the pipeline in-house next year, they can, and the documentation exists to make that realistic. Our application maintenance and support teams are available if you would rather not run it in-house, but that always remains your choice.

It starts with an audit, not a contract

The first step is mapping how your data moves today. That is a scoped piece of work with its own deliverable, and it stands on its own.

If the honest conclusion is that your existing integration is sound and simply needs monitoring around it, we will tell you that, and you will have the map either way.

Symptoms

You already know when you need this

Most of our pipeline projects don't start with someone asking for an ETL. They start with one of these.

Manual exports

Someone begins every day by exporting a file from one system and importing it into another.

Reconciliation by hand

Closing the month means reconciling two systems in a spreadsheet, and that spreadsheet has a maintainer.

Stale reporting

Your reporting describes yesterday, so decisions get made on numbers everyone quietly distrusts.

Conflicting records

The CRM and the ERP disagree about the same customer, and neither side will concede.

Slow propagation

A value changes in the system of record and reaches everything downstream hours later, if it arrives at all.

Overselling

Stock is accurate in the warehouse and wrong on the website, so you oversell.

Orphan integration

An integration is running in production and nobody left in the company fully understands it.

Coupled failures

One system going down takes something with it that has no business being coupled to it.

Positioning

ETL or PIM? Two different problems

The two get confused constantly. They are complementary rather than interchangeable, and the difference decides where you should start.

Content versus movement

Which scenario matches your current operational challenge?

Companies with a product catalogue often need both, and they work well together. The one you need first depends on where the pain actually is.

A PIM problem

Product content is scattered, incomplete or inconsistent. Attributes differ per channel, translations are missing, media lives in five places. The data exists but nobody trusts its quality.

An ETL problem

The data is already correct somewhere, it just isn't where it needs to be yet. Stock, prices, orders and customer records are accurate in one system and stale in every other one.

What a PIM does

Centralises descriptions, attributes, translations and media, enriches them, and publishes a clean catalogue out to every channel.

What an ETL does

Moves operational data between systems on a rhythm tight enough that every system reflects the same reality, and reconciles it when something fails.

If the first column sounds familiar, start with Product Information Management. If the second one does, you're on the right page. The ETL is often what feeds the PIM in the first place.

Approach

Volume, distribution, and the shape of your data

Every data problem has a different shape. French retail chain Bébé9 handed us one of the harder ones: stock spread across more than a hundred independent franchise locations, each moving on its own, with no central point where any of it naturally comes together, and all of it needing to resolve into one number that the outside world can act on.

The reason we cite it isn't the sector. It's that a hundred autonomous sources with no natural consolidation point is the same engineering problem whether those sources are stores, depots, subsidiaries, plants, vehicles or field teams. The pipeline aggregates at the integration layer rather than waiting for a source system to do it, and the commercial definition of "available" gets settled before a single record moves.

Not every business needs that pipeline. A single-source organisation with a nightly update has a genuinely different problem, and pretending otherwise would cost you money. So we start by mapping how your data actually moves today, then define, with you, the frequency, the volume and the failure points that matter most to your business.

Our scope

Audit, build, then watch it

Three phases, from an undocumented data landscape to a sync your team can stop worrying about.

Data mapping and audit Two source systems examined under a magnifier and mapped into a single source of truth, one inconsistency flagged.

Data mapping and audit

Before any pipeline gets built, we need to understand where your data actually lives, who owns it, and how much of it can be trusted. This phase surfaces the undocumented rules, the manual workarounds and the gaps that a straight migration would otherwise carry forward into the new system, intact.

  • Source system and data inventory
  • Data quality and consistency review
  • Business rule discovery, including the rules nobody wrote down
  • Volume, frequency and peak profiling
  • Source-of-truth definition, per data domain
  • Risk and failure-point identification
Pipeline and integration architecture Two source systems feeding a transformation stage that distributes data out to three destinations.

Pipeline and integration architecture

Once we know what's moving and how often, we design the pipeline itself. The goal is an integration layer that holds up under real business volume and real failure conditions, not one that works in a demo.

  • Pipeline and middleware design
  • Product, price, stock, order and customer record synchronization
  • Master and reference data alignment
  • Document and media flow automation
  • Multi-source, multi-destination sync across ERP, CRM, OMS, WMS, PIM and BI
  • Event-driven versus batch strategy, defined per data type
  • Error handling, retry and reconciliation logic
Monitoring and reliability A monitoring panel with two successful checks, one failed check, and a live activity line.

Monitoring and reliability

A pipeline that fails silently is worse than no pipeline at all. We build in the visibility your team needs to trust the data wherever it lands, and to catch problems before the business does.

  • Sync monitoring and alerting
  • Data validation checkpoints
  • Reconciliation reporting between source and destination
  • Performance and load testing under peak volume
  • Rollback and recovery procedures
  • Ongoing maintenance and evolution, if you want it

Systems

How we integrate, and what with

The competence is the integration pattern, not the logo on the box. We pick the transport based on what a system can actually offer, which is regularly less than its documentation claims, and we work with the systems you have rather than the ones we would prefer you had.

Integration patterns

REST, SOAP and GraphQL APIs Event streams and message queues Webhooks Flat file exchange over SFTP (CSV, XML, fixed width) Direct database and read-replica access Scheduled batch windows Continuous sync, chosen per data type Legacy and proprietary interfaces where nothing better is exposed

Systems we sit between

ERP CRM WMS and OMS POS and distributed site networks PIM and DAM BI, reporting and data warehouses Marketplaces, supplier and logistics feeds

Platforms we have delivered against

Magento and Adobe Commerce Sylius and Symfony PrestaShop Custom applications and internal tools

Listed as evidence of what we have shipped, not as a boundary on what we will connect to.

Start with a data flow audit

You don't have to commit to a pipeline to find out what's breaking. We map how your data moves today, where the manual steps are, which failures are currently silent, and which flow would pay for itself first. You keep the map whether or not you build it with us.

Talk to us about your data

Data projects we have shipped

Distributed network
Bébé9

More than a hundred independent stock locations, no central point of aggregation, and a number that has to be right for the outside world. How the pipeline resolves a hundred autonomous sources into one trustworthy figure.

100+
Autonomous sources
0
Manual exports
ETL Aggregation Magento
Read the case study
Marketplace
LS Group

On a vehicle marketplace, inventory changes under you constantly. How our ETL keeps LS Group's inventory, availability and pricing consistent between their systems and the Sylius platform customers see.

ETL Inventory Sylius Symfony
Read the case study
Migration
Carré Blanc

Behind a Magento 1 to Magento 2 migration sat a data problem: consolidating product, stock and price information from multiple sources into a single centralised flow before anything could move.

ETL Consolidation Magento 2 Hyvä
Read the case study

FAQ

Questions we get asked

Do I need a PIM, an ETL, or both?

It depends on where the pain is. If your product content is incomplete, inconsistent or duplicated across channels, that's a PIM problem. If your content is fine but arrives where it's needed too late, that's an ETL problem. Organisations running several channels usually end up with both, and the ETL is often what feeds the PIM in the first place.

See our PIM expertise

Is this only for e-commerce?

No, though that's where a lot of our published work sits. The engineering is the same wherever two systems have to agree: an ERP and a CRM arguing over a customer record, a WMS and a finance system arguing over what shipped, a field system feeding a BI stack that management actually trusts. A storefront is just an unusually public destination, and an unusually unforgiving one, which is a decent way to have learned this.

What does "near real time" actually mean?

Different things for different data, which is rather the point. Values with commercial consequences, stock and price among them, usually need to move within minutes. Reference data and bulk catalogue updates are fine on a slower cycle. We define that trade-off with you, per data type, instead of selling you a single number up front.

What's the difference between an ETL and an API integration?

An API integration connects two systems. An ETL is a layer that extracts data, transforms it to fit the destination's rules, and loads it, with logging, retries and reconciliation around every step. When two systems disagree about what a record should say, an integration passes the disagreement along. The ETL is where you decide who wins, and where you find out that the decision was wrong before it compounds.

What happens when one of my systems goes down?

Downstream systems keep serving the last known good data instead of emptying themselves. Failed batches are queued, retried and reconciled when the source returns, your team gets alerted rather than finding out from a customer or an auditor, and we keep a rollback path for any sync that turns out to have pushed bad data.

Can you work with the integration we already have?

Often yes, and the audit exists to answer exactly that. Sometimes an existing connector is sound and simply needs monitoring and error handling around it. Sometimes it's a script one person wrote and nobody else can read. We tell you which one you have before proposing to replace anything.

Do you work as a project team or as embedded engineers?

Both, and the choice is usually dictated by how much of the knowledge lives in people rather than in documentation. For a bounded pipeline, a project team is efficient. Where the business rules are undocumented and only a few people carry them, it works better to put an engineer alongside your team, close enough to the systems and the people who understand them. That's increasingly how we prefer to work on data projects.

Who owns the pipeline once it's live?

You do. The code, the documentation and the mapping rules are yours. If you would rather not run it in-house, our application maintenance and support teams monitor and evolve it as your systems and volumes change. That's a choice, not a lock-in.

Related

ETL and real-time sync, but also

Tell us how your systems disagree

Bring us the flow that keeps breaking, the export nobody wants to own, or the integration you inherited. We have probably met the problem before, and if we haven't, we will say so.