Migrating Third-Party Models into the Snowflake Model Registry

1.First decision: built-in type or custom wrapper?

Any model you move into Snowflake ends up in the Snowflake Model Registry. You log the model, and the registry stores it as a first-class schema-level object with versions, metadata and role-based access. The registry is built to accept models wherever they came from: it is "flexible and powerful enough to support your own previously-trained models" along with custom processing code. Where the model was trained matters less than what kind of Python object it is.

So the first step in any migration is to check the model's framework against the built-in list. If it is on the list, you pass the in-memory model object straight to log_model and Snowflake handles serialization. If it is not, you wrap it in a CustomModel.

Snowsight offers a second way in. The registry overview notes that "You can also import a model from an external provider to Snowflake," and in the Snowsight import-and-deploy flow you name the version, choose a database and schema, and can add pip requirements. Only packages served from PyPI are supported there. The flow then continues straight into deploying a service.

Sources12

2.Bringing MLflow pyfunc models across

Teams leaving an MLflow-based setup often have models already logged as MLflow pyfunc. Snowflake accepts these directly: "You can use MLflow models that support PyFunc." If the MLflow model has a signature, the registry infers it. If not, you have to supply either a signature or sample_input_data.

What needs deciding during migration is how much of MLflow's packaging comes along. Three keys in the options dictionary of log_model control this.

The dependency switch matters most. An MLflow model records the packages from the environment it was trained in, and Snowflake warehouses may not offer those packages. The documented pattern is to ignore MLflow's dependency list and state your own with conda_dependencies.

model_ref = registry.log_model(
    mlflow.pyfunc.load_model(f"runs:/{run_id}/model"),
    model_name="mlflowModel",
    version_name="v1",
    conda_dependencies=["mlflow<=2.4.0", "scikit-learn", "scipy"],
    options={" ? ": True}
)
model_ref.run(X_test)

Sources3

3.Wrapping pickles and other artifacts with CustomModel

For anything outside the built-in list, you write a subclass of custom_model.CustomModel. Its ModelContext holds what the model needs at inference time, either as in-memory objects of supported types or as file paths. File paths are the usual migration case, because the old platform usually hands over artifacts on disk: "For models or data that are stored in serialized files like Python pickles or JSON, you can provide file paths to your ModelContext." The files get packaged with the model. Your class loads them and exposes methods decorated with @custom_model.inference_api.

# Initialize ModelContext with a file path
# my_file_path is a local pickle file path
model_context = custom_model.ModelContext(
    my_file_path='/path/to/file.pkl',
)

# Define a custom model class that loads the pickled object
class ExampleBringYourOwnModel(custom_model.CustomModel):
    def __init__(self, context: custom_model.ModelContext) -> None:
        super().__init__(context)

        # Use 'my_file_path' key from the context to load the pickled object
        with open(self.context['my_file_path'], 'rb') as f:
            self.obj = pickle.load(f)

    @custom_model.inference_api
    def predict(self, input: pd.DataFrame) -> pd.DataFrame:
        # Use the loaded object to make predictions
        model_output = self.obj.predict(input)
        return pd.DataFrame({'output': model_output})

Three rules prevent common migration bugs. First, if the bundle includes a supported model such as XGBoost alongside unsupported pieces, put that model object directly in the context and Snowflake serializes it for you. Second, always read models through self.context[...]. Assigning an in-memory model directly to an attribute captures a second copy in a closure and makes the model files much larger. Third, write inference methods for multi-row DataFrames. Server-side batching can merge single-record requests into one DataFrame, so a predict function that assumes one row will break once the model is serving real-time traffic.

After the wrapper works locally, you log it like any other model, with explicit dependencies and sample input to infer the signature.

reg = Registry(session=session, database_name="ML", schema_name="REGISTRY")
mv = reg.log_model(my_model,
            model_name="my_custom_model",
            version_name="v1",
            conda_dependencies=["scikit-learn"],
            comment="My Custom ML Model",
            sample_input_data=train_features)
output_df = mv.run(input_df)

Migrated models often rely on helper modules from the old codebase, such as preprocessing or feature utilities. The code_paths parameter packages that code with the model so it can be imported the same way as locally. With string paths, the last component of each path becomes the module name. A CodePath object with a filter lets you include only part of a directory tree, for example leaving out a tests/ folder.

mv = reg.log_model(
    my_model,
    model_name="my_model",
    version_name="v1",
    code_paths=["src/mymodule"],  # import with: import mymodule
)

Sources4

4.Choosing where the migrated model runs

On the old platform the model probably ran in a container you configured yourself. In Snowflake it runs either in a virtual warehouse or in Snowpark Container Services (SPCS), and you choose between them with target_platforms. The choice changes how dependencies are handled. SPCS is also where GPU inference happens, since the registry can "serve the model in Snowpark Container Services for GPU-based inference." Warehouse-deployed models have a size limit of 15 GB.

For migrations, this means a custom-wrapped model gets no automatic dependency inference: you list every package it imports. If those packages come from PyPI, including a private repository your old platform used, set artifact_repository_map so pip packages install from that repository.

Sources1

5.Snowflake-native alternatives to external MLOps tools

Migrating the model is only part of leaving an external MLOps stack. The surrounding jobs (tracking experiments, managing features, versioning data, monitoring, orchestrating pipelines, tracing lineage) each have a Snowflake-native capability, so the workflow can stay where the data is. Snowflake ML is described as flexible and modular, so you can adopt these pieces one at a time rather than all at once.

Experiments are a good example for teams coming from an external tracking tool. Snowflake ML Experiments organize training runs, each with its own metrics, parameters and artifacts, and the results are visible in Snowsight. You can log runs during training on Snowflake, or upload metadata and artifacts from training that already happened elsewhere. The Feature Store can also work with external tools: user-managed feature pipelines can use tools such as dbt.

Sources5678910

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A scikit-learn or XGBoost model trained on another platform has to be wrapped in CustomModel because it came from outside Snowflake.Why is that wrong?

   Built-in support depends on the model's framework, not where it was trained. Log the model object directly and keep CustomModel for types that are not supported.

   Covered in First decision: built-in type or custom wrapper?

2. 2.An MLflow model's recorded dependencies always carry over cleanly, so you never need to override them.Why is that wrong?

   The packages MLflow recorded may not be available in Snowflake warehouses. That is why ignore_mlflow_dependencies exists, so you can supply your own list instead.

   Covered in Bringing MLflow pyfunc models across

3. 3.Inside a CustomModel it is fine to assign the in-memory model directly, as in self.model = model.Why is that wrong?

   Reading the model through the context avoids capturing a second copy in a closure, which would make the serialized model files much larger.

   Covered in Wrapping pickles and other artifacts with CustomModel

4. 4.Moving to Snowflake means every external MLOps tool must be replaced, so user-managed pipelines with tools like dbt are not possible.Why is that wrong?

   Snowflake ML is modular. The Feature Store explicitly supports user-managed feature pipelines with external tools such as dbt, and ML Jobs let teams keep working from an external IDE.

   Covered in Snowflake-native alternatives to external MLOps tools