Simulation model migration: ExtendSim, Plant Simulation and beyond

When migration makes sense

Most migrations start with one of these:

• The model runs on an old version. An Extend model from the 1990s or 2000s may depend on libraries or blocks that newer releases changed or dropped, so it has to be upgraded before it can be trusted again.
• The company standardized on another tool. Your engineering group owns Siemens Plant Simulation, and the ExtendSim model has become the odd one out, or the other way around.
• The people who built it are leaving. The logic lives in the model, not in a document, and only one or two people can read it.
• It's too slow to use for decisions. A run that takes hours can't support a weekly planning meeting, or an answer needed during a disruption.
• The users need an app, not a model. Planners and finance want to change inputs and compare scenarios themselves, in the language of their jobs.

When it doesn't make sense: if the model still answers today's question, runs on a supported version and someone on staff can maintain it, a migration mostly adds risk. Sometimes the right move is a version upgrade plus documentation, not a new tool.

Six migration paths

1. Older Extend or ExtendSim models to the current ExtendSim

This is the lightest path: same tool, same way of thinking. The work is in custom blocks and libraries, database links and any logic that relied on behavior that has since changed. We have built ExtendSim libraries since the early 1990s, including the bulk flow (discrete rate) engine, so we know where older models tend to break.

2. ExtendSim to Siemens Plant Simulation

We made this move ourselves when clients who owned Plant Simulation wanted richer animation and asked us to switch. More than 50 Plant Simulation projects followed. The main work is re-expressing the logic: ModL code in custom blocks becomes SimTalk methods and Plant Simulation objects, and rate-based flows have to be modeled deliberately rather than converted mechanically.

3. Plant Simulation to ExtendSim

Less common, but it comes up for high-speed and bulk lines where a rate-based model runs much faster than one that tracks every container, or when a team wants a lighter tool for many quick studies.

4. Either tool to a custom application

When a model has become a decision tool that many people depend on, we rebuild it as software. VINLogic, a vehicle logistics model first built in our Supply Chain Builder library on ExtendSim, took 6 hours per run. Rebuilt in .NET, it ran in 20 minutes and was used for more than 10 years. Read the VINLogic case.

5. ExtendSim or Plant Simulation to ReliaSim®

For high-speed lines where the question is reliability and OEE, a line model can move into ReliaSim, which plant teams can run themselves. ReliaSim has its own guide to moving a model into ReliaSim.

6. Other tools into any of these

We are tool agnostic. If your model lives in another package and the organization is consolidating, the same method below applies.

The method: validate first, then rebuild

The most common mistake is to start building in the new tool on day one. Do it in this order instead:

1. Inventory. List what the model does, which decisions it supports, its inputs and outputs, custom code, data links and known quirks. Talk to the people who use its answers, not only the people who built it.
2. Baseline. Freeze a set of scenarios and record the old model's results: throughput, utilization, inventory, service levels, whatever the decisions depend on. This set becomes the acceptance test for the new model.
3. Rebuild, don't transliterate. Keep the logic and the data. Don't copy the old structure block by block. Separate the data from the model (a database or spreadsheet the model reads) so the next change is cheaper.
4. Parallel run. Run both models on the baseline scenarios and compare distributions over many replications, not single runs. Agree on the tolerance up front, and explain every difference: some are bugs in the new model, and some are bugs you just found in the old one.
5. Hand off. Document the logic, train the people who will run it, and retire the old model on a date everyone knows.

What doesn't translate one to one

• Rate versus item logic. A bulk flow or high-speed section modeled as rates in ExtendSim has no drop-in equivalent in a tool that moves individual parts, and the reverse is also true. Decide how each section should be modeled in the new tool.
• Random numbers. Two tools will never produce the same single run. Compare averages and spreads across replications.
• Custom code. ModL blocks, SimTalk methods and embedded scripts have to be rewritten. This is also the best time to document them.
• Time bases, warm-up and reporting. Units, warm-up periods and how statistics are collected differ between tools, and small differences here explain many "mismatches".
• Animation. 3D animation in Plant Simulation is often the reason to migrate, but it adds build time. Animate what helps people understand the decision.