Migration
A migration you can verify at every step.
There is no one-click importer, and we will not pretend otherwise. A planning model carries years of site knowledge in its structure, data, and conventions.
Migration is assisted. We map your existing model structure, rebuild process-unit submodels with your team, and run both models side by side until you trust the results.
01The process
Four phases, each with a clear exit.
Phase 1
Map the existing model.
What happens
We walk through your current model with your modelers: units, streams, pools, periods, data sources, and the cases you run each cycle. We document the structure and the conventions that were never written down.
- Your team provides
- Model files and data tables, a set of representative cases, and time with the people who maintain the model.
- Exit with
- A model map and a migration plan with agreed acceptance criteria.
Phase 2
Rebuild process-unit submodels.
What happens
We rebuild each unit as a Slate submodel, working with your team. Yields, qualities, and operating limits carry over, and each submodel is tested against your current model on its own.
- Your team provides
- Review time from the modelers who own each unit.
- Exit with
- Unit submodels with tests that compare them to the current model.
Phase 3
Run both models side by side.
What happens
Both models run the same cases each cycle. Every material difference is investigated until it is fixed or explained. Planners keep using the current model for decisions during this phase.
- Your team provides
- Access to the cycle's cases and a planner to review differences.
- Exit with
- A reconciliation log of every material difference and its cause.
Phase 4
Cut over when you are ready.
What happens
You switch when the acceptance criteria are met, not before. We stay involved through the first planning cycles on Slate.
- Your team provides
- A go or no-go decision against the agreed criteria.
- Exit with
- A production model your team can inspect, test, and adjust.
02What carries over
Your knowledge stays. The structure gets clearer.
Stays the same
- Your process knowledge and unit correlations
- Your data sources and price sets
- Your case definitions and planning calendar
- The way your team reports results
Changes
- Model structure becomes explicit, named, and testable
- Large models can be split into linked subproblems
- Discrete decisions and batch events become part of the model
- Uncertainty is planned for with scenarios, not separate cases
03Timeline
How long it takes.
It depends on model size, the number of sites, and how much of the model is already documented.
[TODO: typical migration timeline by model size, needs approval]
04Questions
Common questions from modelers.
- Do we have to stop using our current model?
- No. It stays in production until the side-by-side results are reconciled and your acceptance criteria are met.
- Is there an automatic importer?
- No. Some steps, such as moving data tables, are scripted. The model itself is rebuilt with your team, unit by unit, because that is where the knowledge is.
- Can our team change the model after cutover?
- Yes. Every submodel is open to inspect, test, and adjust. Your modelers keep the same level of control they have today.
- What if the two models disagree?
- That is the point of the side-by-side phase. Each material difference is traced to a cause: a data issue, a modeling choice, or a better solution. Nothing is waved through.
- What do you need from us to start?
- A conversation with the people who maintain the model, followed by access to the model and a few representative cases.
Next step
See Slate on a model like yours.
Book a working session with the team, or start with the technical brief.