What is an iPaaS? And how does it help you re-align your organisation's data?

Ask a finance director how many customers the company has and you will get a number. Ask the CRM owner and you will get a different one. Ask the eCommerce team and you will get a third. Nobody is lying, and no single system is broken. Each one is answering correctly from inside its own boundary.

That gap is what an iPaaS exists to close.

What an iPaaS actually is

iPaaS stands for Integration Platform as a Service: a platform that sits between the systems you already run and makes them behave like one system.

Concretely, it does five things:

• Connects — to SaaS applications, CRM, ERP, HRM, POS, banking and payment providers, marketplaces, delivery platforms, analytics tools, and the in-house system nobody wants to touch.
• Transforms — reconciles the fact that one system calls it customer_id, another MemberNo, and a third stores it inside a free-text field.
• Orchestrates — runs the business process across those systems: approve, then post to finance, then notify, then issue the invoice, then update the dashboard.
• Governs — one place where authentication, permissions, rate limits, logging and audit trails live, instead of fifteen places.
• Exposes — publishes one clean set of APIs that your mobile app, kiosk, portal or partner integrates against, so surfaces stop talking directly to core systems.

It is worth being equally clear about what an iPaaS is not. It is not a replacement for your ERP or CRM. It is not another database you have to migrate into. It is not a rip-and-replace programme. It is the layer that lets you stop doing rip-and-replace programmes.

The symptoms, before the diagnosis

You do not usually go looking for an integration platform. You go looking because of one of these:

• Two systems disagree, and a person is the integration. Someone exports a spreadsheet from one system every morning and pastes it into another. That person is your integration layer, and they take annual leave.
• A number takes three days to produce. Consolidated figures across regions, plants or business units require a human to gather and reconcile before anyone can look at them.
• Every new channel is a new project. Adding a marketplace, a delivery platform or a payment provider means another point-to-point integration, another set of credentials, another thing to monitor.
• A core system is out of support. The workflow tool or portal that runs your approvals has reached end-of-life, the original vendor is gone, and nobody will touch it.
• A regulator has moved. E-invoicing, tax reporting or data-residency rules changed, and compliance now needs to be enforced consistently across every system that issues a document.
• You cannot ship a customer-facing app. The mobile app the business wants requires data from four systems, two of which have no API and one of which is not on the internet at all.
• Nobody can answer "where did this record come from?" No trace, no audit, no version.

If you recognise three or more of those, the problem is not any individual application. It is that the space between your applications has no owner.

What "re-aligning your data" means in practice

Re-alignment is not a migration. It is four decisions, made once and then enforced by the platform:

1. One system of record per fact. Customers live here. Products live there. Everything else reads. Ambiguity is what produces three different customer counts.
2. One shared shape. A canonical definition of customer, order, employee and invoice that every system maps onto, so translation happens in one place rather than in every connector.
3. One direction of flow. Explicit, documented, monitored. Circular syncs are how two systems overwrite each other for six months before anyone notices.
4. One audit trail. Every movement logged, so the answer to "where did this number come from?" is a query rather than an investigation.

Once those hold, the dashboards stop arguing. Not because you replaced anything, but because the platform in the middle reconciles them by design.

Five patterns from the field

The following are real Redstone deployments. Customer identities are withheld, but the shapes are exact — and one of them will look familiar.

1. The organisation whose platform outlived its own technology choices

A large sports and recreation club group came to us wanting one thing: let members book and pay for facilities — courts, pools, pitches, gym — from their phone.

What was actually built was an integration layer with several surfaces on top. Bookings and payments flow through the platform. On payment, it issues a QR code that reception can validate. For capacity-limited facilities, the platform drives the physical door: a screen at the entrance displays a time-challenged, rotating QR code, and only a member with a paid booking for that exact slot can scan it and be let in. That was our first IoT deployment — the integration platform holding both the commercial transaction and the physical access decision, so the door cannot be opened by a screenshot.

The part worth noting is what happened afterwards. That deployment began on Redstone 1, when the core ran on PHP. The platform has since been rewritten and advanced to Redstone 5.0 on .NET. The mobile app started on Xamarin and is now Flutter. Across every one of those changes, the customer's premises stayed protected and their members kept booking. They bought a capability, not a technology generation — and they have never had to repurchase it.

The pattern: an integration platform is the only layer that can absorb a decade of technology churn on your behalf.

2. The retailer that retired its legacy stack one piece at a time

A nationwide coffee retail chain first adopted Redstone for something narrow: a content management system for their public website. We rebuilt the site, and everything on it — menus, store information, every product page — became content their own team manages.

Then the interesting thing happened. Having one governed platform in place changed how their decision makers thought about the rest of the estate. Legacy systems started being retired into it, deliberately, piece by piece: the CMS first, then delivery-aggregator order information from one platform, then a second, then a third, then their own branded consumer app, then their stored-value card system. Point-of-sale, mobile apps and every delivery channel now meet in the same place.

Today that platform processes up to 50,000 orders a day nationwide and serves around 30,000 daily users, with DDoS protection and security controls built into the layer rather than bolted onto each system. They moved from Redstone 2 to Redstone 3 on .NET 8 a year ago, on the same continuous upgrade path.

The pattern: you do not need a big-bang modernisation. You need one governed integration layer and the discipline to migrate into it one system per quarter. Ten quarters later the legacy estate is gone, and nothing ever went dark.

3. The regulated operator that made compliance a platform feature

When the Malaysian tax authority mandated e-invoicing, every organisation above the threshold had to comply — including a licensed gaming operator with very high transaction volumes and very low tolerance for reporting error.

They adopted Redstone as their e-invoicing integration, and we built the capability into the platform itself. Redstone was the first in its market to support the signed v1.1 e-invoice format — and that version number hides the entire difficulty of the problem.

A v1.0 e-invoice is unsigned. It is a document submitted to the tax authority, and any competent team can produce one. A v1.1 e-invoice is digitally signed, and the signature must be produced with a digital certificate purchased from a certification authority approved by the national regulator. That single requirement changes who is capable of building it. You are no longer writing an integration; you are handling private keys, certificate chains, canonicalisation and digital signature formats correctly — and getting any of it subtly wrong produces a document the authority rejects, or worse, accepts today and disputes later. It needs engineers who have genuinely worked in cryptography, which is not a skill set most in-house teams or integration vendors have on staff.

This is the clearest illustration of what an integration platform is for. Signing was solved once, by people who understood it, inside the platform. Every system that issues a document inherits it. The alternative — each application implementing regulated cryptographic signing on its own — is how organisations end up with five implementations, of which only some are correct, and no way to tell which.

If e-invoicing is the obligation in front of you right now and integration is not, we also ship this capability on its own as E-Invoice — the same signing engine, without adopting a platform to get it.

The same platform then powered their consumer mobile app. Their core system is off-grid — deliberately not internet-connected, as it must be. Redstone sits between: taking results out, passing them through, and notifying customers whose saved numbers have won. Regulation prevents the app from selling anything, so it does one job — and it is used by up to 65,000 people a week.

The pattern: compliance and air-gapped core systems are the two requirements most often used to argue that integration is impossible. They are the two strongest arguments for putting a governed platform in the middle.

4. The manufacturer that took its own workflows back

A precision engineering group ran their company-wide approval workflows on an old collaboration platform. It reached end-of-life, and nobody could maintain it any longer. They were not looking for a bigger product. They were looking for a platform they could customise and then maintain themselves.

They onboarded onto Redstone 3, bought a training package alongside it, and now build and change their own forms and approval flows. Every approval workflow across their operations in Malaysia, Singapore and the Philippines runs on it, configured by their own team.

They also use Redstone's DataOps capability to run daily ETL, combining production-plant data from all three countries and feeding the consolidated figures into Power BI. Management reporting that used to be assembled by hand now arrives as a pipeline output.

The pattern: the fastest route out of an unmaintainable system is not another vendor dependency. It is a platform your team can operate — and the same platform that fixes approvals also fixes reporting, because both are integration problems wearing different clothes.

5. The brand that kept the system it was happy with

Our most recent large enterprise onboarding is a fast-growing coffee brand. They wanted a consumer mobile app, and their customer loyalty programme already lived in a separate platform they had no intention of moving.

So we did not move it. Redstone integrated the existing loyalty system and delivered the app on top. It now serves around 10,000 customers a week, nationwide.

The pattern: the right answer is often "keep it and integrate it." An iPaaS earns its place precisely by not demanding replacement.

What those five have in common

Different industries, different regulators, different technology. The same five properties:

• Integration first, replacement never. Every one of these deployments left working systems in place — POS, loyalty, an off-grid core, plant systems — and connected them.
• One platform, many surfaces. Mobile apps, kiosks, websites, physical doors and partner APIs are all just presentation layers over the same governed core. Adding a surface stops being an integration project.
• The middle is owned. Authentication, logging, rate limiting, DDoS protection, audit and error handling are properties of the layer, not per-system afterthoughts.
• Compliance is implemented once. Signed e-invoicing was built into the platform, so every customer inherits it instead of building it.
• Continuity is designed in. PHP to .NET, Xamarin to Flutter, Redstone 1 to 5.1 — the business logic carried forward. Redstone ships with up to 10 years of LTS on one continuously maintained upgrade path, and we deliver that by moving customers forward, not by freezing them.

Questions to ask before you buy an integration platform

Not all iPaaS offerings are the same shape. These five questions separate them quickly:

1. Where does it run? If your data cannot leave your jurisdiction, your tenancy or your building, a cloud-only platform is not a candidate. Redstone runs on Windows, Linux (x64 and ARM64) and macOS — on-premise, in your own cloud tenancy, headless, or fully air-gapped.
2. Can it reach systems that are not on the internet? Real estates contain off-grid core systems, plant equipment and legacy servers. Ask specifically.
3. Can your team maintain it? If every change is a change request, you have swapped one dependency for another. Ask whether your people can be trained to build workflows themselves.
4. What is the support horizon? Integration layers are load-bearing for a decade. Ask what happens at end-of-life, and whether you end up on a fork.
5. Does it do more than move records? Mobile apps, kiosks, IoT, ETL and BI feeds are all downstream of the same integration layer. A platform that only pushes JSON between SaaS apps leaves you shopping for four more vendors.

Where to start

Re-alignment does not start with a platform decision. It starts with a map: list your systems, then draw every place data moves between them — including the spreadsheets and the people. Most organisations find something they did not know existed within an hour.

Then pick the single worst flow. Not the biggest — the worst. The nightly export somebody does by hand, the report that takes three days, the compliance obligation currently held together by discipline. Fix that one properly, through a governed layer, and you will have both a working integration and a template for the next twenty.

Every customer above started with exactly one flow. A website. A booking screen. An invoice format. An approval form.

If any of the symptoms in this post describe a system you are responsible for, get in touch. Tell us the one flow that hurts most, and we will walk you through how Redstone would handle it — on your infrastructure, against your systems.