Every MES vendor with more than one acquisition in its history eventually faces the same reckoning: too many product lines, too much duplicated engineering effort, and customers asking why the process plant version and the discrete plant version of “the same product” don’t share a codebase. Siemens is now working through that reckoning with Opcenter Execution, and the vehicle is Opcenter Execution Core — a consolidated, low-code execution engine that Siemens is positioning as the long-term successor to Opcenter Execution Foundation, Opcenter Execution Process, and Opcenter Execution Discrete/Pharma.
If you’re running one of the legacy products today, you’ve probably already seen the roadmap slides. The question isn’t whether Siemens wants you on Core eventually — that much is clear from partner briefings and product direction. The question is what moving actually costs you in engineering time, validation effort, and operational risk, and whether the timing is yours to control or Siemens’.
What Opcenter Execution Core actually is
Opcenter Execution Core is Siemens’ attempt to build one execution engine that serves process, discrete, and hybrid manufacturing from a common architecture, rather than maintaining three historically distinct products that grew out of different acquisitions (Camstar for discrete/pharma, SIMATIC IT for process, and the Foundation line that tried to bridge them). Core is built around a low-code configuration model — workflows, forms, and business logic assembled through configuration tools rather than heavy custom scripting — with the stated goal of shrinking the amount of custom code a systems integrator has to write and maintain for each site.
That’s a real architectural shift, not just a UI refresh. The data model, the workflow engine, and the extensibility model are different enough that Siemens treats Core as a distinct product line with its own implementation methodology, not a service pack on top of the existing Opcenter Execution products. In our assessment, that’s the right call technically — bolting a low-code layer onto three separate legacy codebases would have been messier than starting from a common core and building connectors and migration tooling outward. But it also means “upgrade” is the wrong mental model. This is a migration.
What’s genuinely re-platformed versus what’s rebranded
It’s worth being precise here, because vendors under consolidation pressure have an incentive to blur the line between “new architecture” and “new marketing name for the old thing.” Based on Siemens’ own technical positioning, the workflow/rules engine and the low-code configuration layer in Core are new relative to the classic Opcenter Execution products. The underlying philosophy — model-driven execution tied to ISA-95 and ISA-88 concepts, master data for routings, materials, equipment, and specifications — carries over conceptually, because that’s industry-standard MES thinking, not something unique to one codebase.
What doesn’t automatically carry over is your site-specific configuration: the custom screens, the electronic batch record templates, the interlocks and business rules your integrator built for you in the legacy product’s scripting environment. Those were built against the old data model and the old extensibility framework. In a low-code re-platform, that logic generally has to be reconstructed in the new tool, not lifted and dropped in. That’s the crux of the migration cost question, and it’s where a lot of the roadmap conversation glosses over the work involved.
What migration really costs — in effort, not dollars
Nobody should tell you a number here, because it depends entirely on how customized your current implementation is, and anyone quoting a firm figure this early in a partner-led migration program is guessing. What’s predictable is the shape of the effort:
- Template and workflow rebuild. Custom electronic batch records, work instructions, and routing logic built in the legacy scripting environment need to be reconstructed in Core’s low-code tools. This is typically the largest line item, and it scales with how heavily customized your original implementation was rather than with plant size.
- Re-validation, for regulated sites. If you’re running Opcenter Execution Pharma or any GxP-scoped instance, moving to a new architecture is a validation event, not a patch. Expect IQ/OQ/PQ activity scoped to the new platform, plus a look at whether your validation master plan treats this as a like-for-like replacement or a new system — that determination drives a lot of downstream effort.
- Integration rework. Interfaces to ERP, historians, LIMS, and shop-floor equipment via OPC UA or MQTT/Sparkplug B connections were built against the legacy product’s interface layer. Those adapters typically need re-testing at minimum, and in some cases rebuilding, against Core.
- Operator retraining and change management. A new low-code UI paradigm changes how screens render and how operators navigate, even if the underlying process logic is conceptually identical. Don’t underestimate this on a 24/7 line where muscle memory matters.
This pattern — a platform consolidation that forces re-validation and template rework on customers of the “old” product line — isn’t unique to Siemens. Rockwell Automation’s customers running FactoryTalk PharmaSuite and ProductionCentre have faced comparable platform-direction decisions as Rockwell has consolidated its MES portfolio. If you’ve been through one of those transitions, the Opcenter Core decision will feel familiar: the vendor’s roadmap is rational at the portfolio level, and the customer’s job is to manage timing and risk at the plant level.
Who this fits well, and who should be more cautious
Core is a strong fit for greenfield sites, for companies standardizing a template across many plants (where low-code configurability genuinely pays off across the fleet), and for shops whose current Opcenter Execution implementation is close to out-of-the-box — thin customization means thin migration effort. It’s also a reasonable fit for multi-site operations that want one architecture spanning process and discrete lines instead of running two Opcenter product families.
In our assessment, Core is a harder sell right now for heavily customized, single-site, validated pharma or biologics operations where the existing Opcenter Execution Pharma implementation is deeply embedded in a mature validation program. For those sites, the re-validation burden alone may argue for waiting until Siemens’ migration tooling and templates for regulated industries mature further, and until there’s a clearer published end-of-life timeline for the legacy products forcing the issue.
A decision checklist
- Move now if you’re greenfield, planning a multi-site standardization program, or your current implementation is lightly customized.
- Wait if you’re deep in a validated GxP environment with heavy custom template work and no forced end-of-life date yet from Siemens for your specific product version.
- Run parallel instances if you have multiple plants and can pilot Core at one lower-risk site while your validated or highly customized sites stay on the legacy product until migration tooling and your internal playbook mature.
- Ask your Siemens account team directly for the supported-lifecycle timeline of your specific Opcenter Execution version — not the roadmap slide, the actual maintenance commitment — before you commit capital either way.
Bottom line
Opcenter Execution Core is a legitimate architectural consolidation, not a cosmetic rebrand — the low-code engine and unified data model are real engineering work, and the direction makes sense for Siemens’ long-term portfolio. But for existing customers, “the vendor’s architecture is better” and “my migration is worth doing this year” are two different questions. The re-validation and template-rework cost is real, it scales with how customized you are today, and it belongs on a project plan with its own budget and timeline — not treated as a routine upgrade tucked into next year’s maintenance renewal. Sites with light customization and multi-plant ambitions should lean toward moving deliberately. Heavily validated, heavily customized single sites have earned the right to wait for a clearer forced timeline before spending that effort twice.
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.
