ML model migration: what survives a platform move

Typically, a data platform migration begins with tables. The plan enumerates sources, schemas and pipelines, and the reconciliation checks are defined early. Later in the programme, a question arises about the machine learning models that score leads, forecast demand or flag fraud. It becomes evident that no one has documented what those models require to continue functioning on the new platform.

ML model migration refers to moving a trained machine learning model and its dependencies from one platform to another. The aim is to guarantee the model yields the same predictions within an agreed tolerance level. Transferring the model file itself is usually straightforward. Nevertheless, features, pipelines, monitoring systems and permissions are specific to the original platform. These components need to be rebuilt and revalidated on the new system.

This guide is for the data and platform leads who own that question. It covers why models are harder to move than tables, what transfers and what must be rebuilt, the open formats and registries that make a move easier, a checklist for planning a model migration alongside a data platform move, how to re-validate a model after the move, and when retraining is the better choice.

We build data foundations and the AI that runs on them, and model migration is part of that work. A pattern we see in platform moves is simple. Teams plan the data move carefully and treat the models as files to copy. The files copy without error, and the predictions then change in ways that nobody notices for weeks.

Why models are harder to move than tables

A table is composed of data with a schema. You can copy it to a new platform, count the rows, and compare the values to confirm it arrived intact. A model does not operate this way; it is a learned function. Its behaviour relies on its training data, the code that prepares its inputs, the libraries used to build it, and the environment where it runs. If any of these factors change, the model may yield different results even while running without errors.

Model failures after a migration are typically silent. A broken table load will generate an error message. However, a feature computed with a different date function or a null value treated as zero yields a valid yet incorrect number. The model accepts this data and produces a prediction. Machine learning teams call this training-serving skew, which happens when the inputs at prediction time do not match the inputs used during training.

The model consists of more than just the file

Before planning a move, enumerate all the dependencies of your production model. In most environments, the list comprises the following items.

• The trained artefact includes the weights or fitted parameters, which are stored in a specific file format.
• The preprocessing code includes scaling, encoding, text cleaning and any business rules applied before the model sees the data.
• The features: how each input is calculated, from which tables, at what time and on what refresh schedule.
• Training data refers to the specific snapshot or query used to train the model. You must retain this data if you need to retrain the model or conduct an audit later.
• The serving environment includes the runtime, library versions, hardware and the endpoint or batch job that calls the model.
• The operational layer comprises pipelines for retraining and scoring, monitoring systems that detect drift, and alerts that notify personnel of failures.
• The access layer includes the roles, service accounts, and grants that enable the model to read data and allow applications to call the model.

You can reconcile a table that moves correctly. You must revalidate a model even if it moves correctly.

What you can transfer and what you must rebuild

Not every part of a model transfers with the same effort. The division below applies across most platform pairs, whether the move is from on-premises servers to a cloud warehouse or between platforms such as Databricks, Snowflake, Google BigQuery and Microsoft Fabric.

What usually moves cleanly

• Code. Training and inference code written in Python or SQL and stored in version control moves with minimal changes. You only need to update connection details and fix dialect issues.
• Weights in open formats. You can typically load a model on a new platform without retraining if it is saved in a framework-neutral format like ONNX or packaged in the MLflow model format.
• Feature logic written as code. Features defined in SQL or Python files, rather than as objects inside a platform's interface, can be pointed at the new platform and run again.
• Training data in open file formats. Data exported to Parquet or an open table format keeps its types and can be read by every major platform.
• Documentation and evidence. Model cards, validation reports and approval records are platform-neutral and become the baseline for the new environment.

What usually has to be rebuilt

• Platform-specific feature stores. Managed feature stores link feature tables, online serving, and lineage to the catalogue of a single platform. The definitions can be recreated, yet the store itself cannot be moved. Our guide to the role of a feature store in MLOps explains the functions of that layer.
• Pipelines and schedules. Training and scoring jobs need to be rebuilt in the new orchestration tool. This also requires moving all dependencies and retry rules from the old platform.
• Serving endpoints. Endpoints, scaling settings, and authentication are managed by the platform. You perform the model deployment step again rather than copying it.
• Monitoring. Drift jobs, baselines, and alerts are typically built with platform tools. These need to be recreated and directed at the new data. Our guide to model monitoring in production describes this process.
• Permissions. Roles and grants seldom match exactly across platforms. They should be rebuilt according to the access policy rather than translating the old configuration.
• Manage the lineage and audit history. Platform metadata often holds records indicating which data trained particular versions. Export or summarise this information before deactivating the old platform.

Environment and versions: the grey zone

Some parts appear to move cleanly and do not. A model saved with Python's pickle format loads reliably only with the library versions it was saved with. A newer library may load the file but change a default. SQL functions for dates, rounding and string handling differ between warehouse dialects, so a feature query that runs on both platforms can return different values. Numerical results can also differ slightly between hardware types. None of these raise an error. All of them must be checked.

Useful formats and registries

Portability is a property you build in. Models built with open formats and recorded in an open registry move with far less rework than models built inside one platform's tools. Four choices make the most difference.

ONNX for model weights

ONNX, the Open Neural Network Exchange format, is an open standard for representing trained models. Models from frameworks such as PyTorch, TensorFlow and scikit-learn can be converted to ONNX and run with ONNX Runtime on many platforms and hardware types. It suits models that need to run outside the environment where they were trained. It has limits. Not every operation converts, custom preprocessing often sits outside the ONNX graph, and every conversion must be tested against the original model's outputs.

MLflow for packaging and history

MLflow is an open-source tool that tracks experiments, packages models, and manages them in a registry. During a migration it performs three specific functions. The model format stores the artefact together with its environment requirements and its input and output signature. This information enables the new platform to load and invoke the model correctly. The tracking records hold the metrics and parameters used to train each version, providing a baseline for re-validation. The registry offers an inventory of model versions and their current stages. MLflow is offered as a managed service on multiple platforms or as an independent installation. This enables you to export registry contents and register them again on the target platform.

Open feature stores and features managed as code

Feast is an open-source feature store that lets you define features in code and connect to various offline and online stores. Keeping feature definitions in version control with Feast, dbt models, or SQL keeps the logic within the repository rather than confined to a specific platform. A strong data foundation also supports this process. Building features on governed gold tables with standardised business definitions reduces the hidden logic you must identify when moving systems. Our guide to feature engineering explains the design process for these inputs.

Containers for the serving environment

Packaging the inference service as a container image fixes the operating system, runtime and library versions in one artefact. The same image can run on most cloud platforms, which removes a large share of version problems. It does not remove the need to rebuild endpoints, scaling and access around it.

You determine a model's portability during the building phase rather than during the transfer process.

A checklist for migrating models

Plan model migration as part of the data platform move, not after it. Models depend on tables, so their sequence follows the data. The checklist below assumes the data move already has reconciliation built in, as described in our cloud migration roadmap.

Before the move

• Create a list of all models currently in production. For each model, list the owner, the purpose, the consumers, and the specific business metric it supports.
• List each model's dependencies. Include the source tables used, the queries for features, any lookup data, schedules that trigger the model, the secrets it accesses, and the applications that use its output.
• Choose a path for each model: move it without changes, rebuild it using the same artefact, retrain it on the new platform, or retire it.
• Capture baselines on the old platform: predictions on a frozen evaluation set, current production metrics, feature distributions and latency.
• Sequence each model after you have migrated and reconciled the tables it reads.

During the move

• Rebuild the feature logic on the new platform. Then compare the feature values from the new platform with the values from the old platform for the same entities and dates.
• Package the model with pinned library versions and register it with a link back to its previous version.
• Recreate access from the policy, giving the model and its callers only the permissions they need.
• Run the new model together with the existing one and score the same inputs before switching the application to the new version.

After the move

• Rebuild monitoring and carry over the baselines captured before the move.
• Keep the previous model and pipeline for a defined period so you can revert to them if needed.
• Do not deactivate old pipelines until formal approval is received from both the model owner and the business owner.
• Document each change so the next audit can track the model across both platforms.

Re-validation after the move

A migrated model constitutes a new deployment. It must satisfy the same checks as any other new deployment. Re-validation consists of comparing the new model with your original baselines at three levels. Our guide to model validation and testing describes the general process. The following points apply specifically to the migration process.

Feature parity

Compare each feature on both platforms using a sample of entities and dates. Examine the distributions, null rates, and exact values. Most migration errors happen at this stage. Fixing these errors now is less costly than discovering them in the predictions later.

Prediction parity

Evaluate a fixed dataset on both platforms and compare the outcomes. Set acceptable tolerance levels before reviewing the data. A model transferred in the same format with identical library versions should yield nearly identical results. A converted model may exhibit minor numerical differences. For classification tasks, compute the frequency of identical predictions between the two versions. For ranking and forecasting, assess the degree of variance between the outputs.

Business performance

Run the new model in shadow mode with live inputs. Continue this process until standard data cycles, such as month-end periods and seasonal peaks, are covered. Evaluate the business metrics the model supports, together with its latency and serving costs. Keep all evidence from this period. Auditors or regulators may require documentation to demonstrate that the model operates according to its approved specifications.

When to retrain instead

Moving the existing artefact is not always optimal. In such cases, retraining on the new platform is often a cleaner approach.

• The old artefact cannot be loaded or converted, for example because it was built in a proprietary tool or an unsupported library version.
• The feature logic cannot be reproduced exactly, so the model would receive inputs that differ from what it learned.
• The model was losing accuracy before the move took place. Our guide to model drift explains how to identify this issue.
• The new platform includes improved data, such as cleaner historical records and governed features that were previously unavailable.
• The model is simple and can be trained quickly. Therefore, the cost of retraining is lower than the cost of proving a conversion.

Retraining entails specific costs. A retrained model operates as a new model. It requires full validation against business outcomes, new approval if governance rules demand it, and a comparison with the previous model. You should plan for this work rather than treating retraining as a shortcut.

Some models should be decommissioned. If a model lacks an owner, has no current users, or yields no measurable results, you should consider retiring it. A migration offers an opportunity to make these decisions.

What these points mean for you

ML model migration succeeds when the model is regarded as a system rather than a file. Code and weights in open formats transfer cleanly. Feature stores, pipelines, endpoints, monitoring, and permissions are rebuilt. The work that determines the outcome occurs around the move: an inventory, baselines captured before any changes, sequencing behind the data, and re-validation at feature, prediction, and business level.

If you plan to move a data platform, include the model inventory in the plan now. For each model, decide whether it will be moved, rebuilt, retrained, or retired. The data move and the model move can then follow the same sequence, use the same reconciliation checks, and have a single final sign-off.

We plan and deliver model migration as part of the data foundation. This effort runs together with the warehouse, medallion architecture, and the semantic layer used by the models. If a project includes a warehouse or cloud transition, our data migration service aligns data row by row and offers post cutover support, with models being handled subsequently. We assess which components can be transferred, which need to be rebuilt, and which ought to be retired. We will let you know when a model is not worth moving. Talk to us before setting a cutover date so we can incorporate the models into the initial plan.

Frequently asked questions