Every RFP cycle used to come down to a shootout between two or three MES suites. That’s no longer true. A growing share of plants are now evaluating a third path: build the connectivity and historian layer on Inductive Automation’s Ignition platform, then bolt on a frontline operations app layer like Tulip to handle work instructions, andon, and operator data collection. It’s not a suite. It’s a stack you assemble. And it’s showing up as the credible alternative line item in more and more MES RFPs, right next to Opcenter, Plex, and Critical Manufacturing.
This piece isn’t going to tell you composable wins or suites win. It depends on what your plant actually looks like, who’s on your team, and how much integration risk you’re willing to own. Here’s how to work through that decision honestly.
What each architecture actually is
Ignition is a SCADA and industrial application platform: OPC UA and MQTT/Sparkplug B connectivity, a tag historian, scripting in Python (Jython), and a web-deployed visualization layer. It’s licensed per-server with unlimited clients and unlimited tags in most editions, which is the detail that got it into so many plants in the first place. On its own, Ignition is not an MES — it doesn’t natively give you structured work orders, genealogy, or ISA-95-style production scheduling. It’s the connectivity and data backbone you build on top of.
Tulip, and platforms like it, sit at the other end: a low-code app builder purpose-built for frontline workflows — operator guidance, digital work instructions, andon triggers, quality checklists, machine data capture through its own edge devices or via integration. It’s built for the human-in-the-loop layer of manufacturing execution, not for deep plant historian work or complex controls integration.
Pair them and you get a stack: Ignition handles machine connectivity, historization, and SCADA visualization; Tulip (or a comparable app platform) handles the operator-facing workflow and app layer; you glue them together, usually via MQTT, REST APIs, or a shared database. Opcenter (Siemens), Plex (Rockwell), and Critical Manufacturing represent the opposite bet: one vendor, one data model, one contract, covering scheduling, genealogy, quality, and often connectivity, out of the box.
Where the composable stack genuinely wins
The strongest case for Ignition plus an app layer is speed to a first working system and control over scope. Because Ignition’s licensing isn’t metered by tag count or client seat in the way many suite platforms are, a plant with a lot of PLCs, a lot of tags, and unpredictable client counts can scale connectivity without triggering a licensing conversation every time it adds a line. Time-to-first-workflow tends to be genuinely fast: a controls engineer who already knows Ignition can have live machine data on a screen in days, and a low-code app layer can put a usable digital work instruction in front of an operator in a similarly short cycle, without a lengthy configuration or implementation-partner engagement.
It also fits plants that don’t want to commit to one vendor’s full data model up front. You can start with SCADA and historian work on Ignition, add the app layer for one work cell, prove it out, and expand — a genuinely incremental adoption path that’s harder to do with a suite designed to be deployed as a connected whole.
Who this fits best
- Plants with strong in-house controls or software talent who are comfortable owning integration long-term, not just at go-live.
- Multi-site operations with heterogeneous PLC vendors and legacy equipment where a flexible connectivity layer matters more than a prebuilt data model.
- Organizations that want to pilot MES-like functionality in one area before committing capital to a plant-wide rollout.
- Teams pushing back specifically on subscription-only, per-user suite pricing and wanting more predictable, usage-based cost as they scale tags and connections rather than seats.
Where the monolithic suite still earns its keep
The honest tradeoff is integration ownership. When you buy Opcenter, Plex, or Critical Manufacturing, you’re buying a data model that already understands work orders, routings, genealogy, and quality holds as connected concepts, and a vendor who is contractually on the hook for making that model work end to end. When you build a composable stack, you are the integrator, indefinitely. Every firmware update on a PLC, every schema change in the app layer, every new site with a different network topology becomes your team’s problem to reconcile, not a vendor support ticket. That’s a real ongoing cost, even if it never appears as a line item on an invoice — it shows up as engineering hours, and as risk when the person who built the integration leaves.
Suites also tend to win on things that are unglamorous but expensive to redo: audit trails for regulated industries, electronic batch records, built-in genealogy and traceability that satisfies FDA or automotive customer audits without custom development. If your plant needs validated, out-of-the-box compliance workflows, building that yourself across two platforms is a heavier, riskier lift than a suite vendor who has already done it for other customers in your industry.
Who a suite fits best
- Regulated industries (pharma, medical device, aerospace) where validated traceability and electronic records are non-negotiable and audit-ready out of the box matters more than customization speed.
- Plants without a dedicated software/controls team willing to own long-term integration maintenance.
- Multi-plant enterprises standardizing on one data model globally, where consistency across sites outweighs local flexibility.
The scoring framework: run this on your own plant
Rather than a feature checklist, score your situation against five questions:
- Integration ownership. Do you have staff who can own connector maintenance and app-layer glue code for years, not just at rollout? If not, weight toward a suite.
- Licensing shape. Model your actual growth: tags, connections, and servers (Ignition-style) versus users and sites (suite-style). Project three to five years out, not just current headcount.
- Time-to-first-workflow. How fast do you need something live on the floor? Composable stacks generally win here for a single line or cell.
- Upgrade and patch burden. Suites bundle upgrades under one contract; composable stacks mean coordinating version compatibility across two or more independently-released platforms.
- Ceiling beyond the starter tier. What happens when you outgrow a free/community edition or a single-site pilot? Understand the real cost and complexity of scaling each option to full plant or multi-site deployment before you commit — not just the entry price.
Bottom line
In our assessment, the composable Ignition-plus-app-layer stack is the right default for plants with real in-house technical capability, heterogeneous equipment, and a desire to prove value incrementally before betting the plant on one data model. The unified suite is the right default for regulated environments, thinly staffed IT/OT teams, and enterprises that need one throat to choke and one data model across many sites. Neither is the universally correct answer for 2026 — the honest answer is that the right choice depends on who’s going to own the integration on Tuesday morning eighteen months after go-live, and whether that’s a job your team wants.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
