If you’re a plant IT lead or controls engineer holding a Honeywell MES, historian, or asset performance management contract, you’ve probably noticed the branding shifting under you. Products that used to carry their own product names and roadmaps are increasingly being folded into Honeywell Forge, the company’s umbrella platform for industrial software, data, and analytics. That consolidation has been underway for several years, but it’s accelerating, and it’s landing right as a lot of legacy contracts hit renewal. That timing is not a coincidence, and it’s worth understanding before you sign anything with a multi-year term.
This isn’t a story about Honeywell doing anything wrong. Portfolio consolidation after a run of acquisitions is normal, and every large industrial software vendor eventually does it — Honeywell has built out its software business over time through a series of acquisitions spanning SCADA, historian, and asset/process performance tools, and folding them into a common platform is a predictable next step. The practical question for practitioners isn’t whether consolidation is happening. It’s what it means for the specific system you’re running today, and how to protect yourself contractually while the dust settles.
Why “Forge” isn’t one thing
Honeywell Forge is best understood as a platform strategy and a commercial umbrella more than a single monolithic product. Under that umbrella sit capabilities that trace back to different original codebases, different data models, and different engineering teams — some built in-house, some absorbed through acquisition. That matters because “moving to Forge” can mean very different things depending on which legacy product you’re running. For one plant it might mean a genuine re-architecture onto a common data model and a modern API layer. For another it might mean the existing product keeps running largely as-is, with a new dashboard or licensing wrapper on top and a Forge logo on the login screen.
Both of those are legitimate strategies. The problem is that from the outside — sitting in a renewal meeting — they can look identical. The account team’s job is to sell the platform vision. Your job is to figure out which version of that vision applies to the specific module keeping your plant floor running.
Sorting active development from maintenance mode
Every vendor with a large legacy portfolio ends up with a spectrum: products getting real engineering investment, products getting security patches and not much else, and products on a slow glide path to end-of-life. The trouble is vendors rarely say that plainly in a sales cycle. Here’s a framework for figuring out where your system actually sits.
Look at the release cadence, not the roadmap slide
Roadmap slides are marketing documents. Ask instead for the actual release history of the specific module you run — patch frequency, feature releases, and whether recent releases have added net-new capability or just compatibility fixes. A product still getting quarterly feature releases is in a different category than one that’s had nothing but security patches for several release cycles.
Ask who owns the code today
Acquired products sometimes keep their original engineering team intact for years; sometimes that team is dissolved or redeployed within a year or two of the deal closing. Ask directly whether the engineering organization behind your product is the original team, a Honeywell-integrated team, or a much smaller sustaining-engineering function. You won’t always get a precise answer, but the quality of the answer itself tells you something.
Check whether new capability lands in the legacy product or only in Forge-native tooling
This is often the clearest signal. If new analytics, connectivity, or reporting features are being built exclusively into the Forge-native layer and the legacy product only gets bug fixes, that’s a strong indicator the legacy product is functionally in maintenance mode, whatever the sales materials call it.
Questions to put to your account team before you sign
A few pointed questions, asked directly and in writing, will do more for you than any amount of reading between the lines on a roadmap deck.
- API stability: Are the APIs my current integrations depend on (to SCADA, historian, ERP, or custom MES middleware) staying stable, or are they being deprecated in favor of a new Forge API layer? What’s the deprecation notice period if they change?
- Data model migration: If I move to Forge-native tooling, is historical data migrated automatically, migrated with professional services engagement, or left behind? Who is responsible for validating that migrated data matches source data, and what does that validation process actually look like?
- Licensing bundling: Is the contract being restructured so that modules I don’t currently use are bundled into a Forge subscription, and does declining those bundled modules affect pricing on the parts I do use? Get the itemized breakdown, not just the bundled number.
- Contract term versus product certainty: Will Honeywell commit in writing to a support horizon for the specific legacy product I run, independent of Forge migration timing? A vendor confident in a product’s future should have no trouble putting a support commitment in writing.
- Rollback path: If a Forge migration underperforms or stalls, what’s the contractual and technical path back to the legacy system, and for how long does that path remain available?
What this means for renewal timing
None of this argues against Forge as a direction — platform consolidation after acquisitions is standard industry behavior, and a unified data model with modern APIs is a legitimate improvement over a patchwork of siloed acquired tools, assuming it’s executed well. The risk isn’t the strategy; it’s signing a multi-year commitment before you’ve pinned down where your specific module sits in that transition.
Where possible, negotiate shorter renewal terms or explicit exit/migration clauses rather than locking into multi-year Forge commitments sight unseen. If your Honeywell account team can’t answer the API, data migration, and licensing questions above with specifics rather than reassurance, that’s useful information too — it tells you the migration plan for your product isn’t fully baked yet, and you’re being asked to commit ahead of the vendor’s own certainty.
Plants running legacy Honeywell MES, historian, or APM systems aren’t in a bad position. They’re in a normal one — the same position every plant eventually reaches with every long-tenured industrial software vendor. The difference between a smooth transition and a painful one usually comes down to whether the questions above got asked before the signature, not after.
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.
