Introduction

The old convert_variables_to_constants() API was designed for TensorFlow 1.x graph workflows, where developers manually built graphs, owned sessions, and often "froze" graphs for deployment. TensorFlow 2 changed that execution model, so the old API no longer fit the main programming style and was replaced by newer graph-freezing paths.

What the old function used to do

In TF1, model variables often lived in a graph plus session world. If you wanted a deployment artifact with weights embedded as constants, you would freeze the graph by replacing variable reads with constant tensor values.

That made sense when deployment often meant shipping a frozen GraphDef.

Why TensorFlow 2 made it awkward

TF2 defaults to eager execution and encourages tf.function, Keras models, and SavedModel. Those abstractions no longer revolve around "take my current session graph and freeze it" as the primary deployment story.

So the old API became a mismatch for three reasons:

• it was tightly coupled to TF1 graph-session semantics
• TF2 encourages higher-level export flows such as SavedModel
• graph freezing still exists, but it happens through newer concrete-function APIs

The function was not deprecated because the concept became useless. It was deprecated because the old interface reflected the wrong mental model for TF2.

The TF2 replacement pattern

In TF2, if you really need a frozen graph, the usual route is to trace a tf.function, get a ConcreteFunction, and freeze that.

1import tensorflow as tf
2from tensorflow.python.framework.convert_to_constants import convert_variables_to_constants_v2
3
4class MyModel(tf.Module):
5    @tf.function(input_signature=[tf.TensorSpec([None, 1], tf.float32)])
6    def __call__(self, x):
7        return x * 3.0
8
9model = MyModel()
10concrete = model.__call__.get_concrete_function()
11frozen = convert_variables_to_constants_v2(concrete)
12
13graph_def = frozen.graph.as_graph_def()
14print(len(graph_def.node))

This is the TF2-style freezing flow: start from a concrete function rather than a session-bound graph.

Why SavedModel often removes the need entirely

For many deployment cases, you do not need to freeze variables into constants manually anymore. SavedModel already captures the model graph, variables, and signatures in the format TensorFlow tools expect.

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Dense(4, activation="relu"),
5    tf.keras.layers.Dense(1),
6])
7
8model.build((None, 3))
9tf.saved_model.save(model, "exported_model")

That export path is usually better aligned with TensorFlow Serving, conversion tools, and modern TensorFlow deployment workflows.

When freezing is still useful

Frozen graphs still matter in some specialized cases, such as low-level graph inspection, legacy deployment pipelines, or conversion workflows that explicitly want constants embedded in the graph.

The difference is that TF2 treats freezing as a specialized operation, not the default way every model should be exported.

Deprecation is also a documentation signal

Another reason the old API was deprecated is discoverability. If TF2 continued to promote a TF1-style freezing helper as the obvious first answer, developers would keep reaching for session-era solutions even when SavedModel or higher-level converters were a better fit.

So the deprecation also teaches the new export hierarchy: first ask whether SavedModel is enough, then freeze only if a downstream tool explicitly requires it.

Common Pitfalls

A common mistake is searching for a one-line TF2 replacement while still thinking in pure TF1 session terms. The replacement exists, but the workflow is different.

Another issue is freezing a graph when SavedModel would have been the better export format. Many deployment pipelines do not need manual freezing anymore.

It is also easy to rely on internal or compat APIs without checking whether the tool you are targeting actually requires a frozen graph.

Summary

• 'convert_variables_to_constants() was tied to TensorFlow 1.x graph-and-session workflows.'
• TensorFlow 2 centers eager execution, tf.function, Keras, and SavedModel instead.
• Freezing still exists, but TF2 usually does it from a ConcreteFunction with newer APIs.
• Many deployment workflows no longer need manual graph freezing at all.
• The deprecation reflects a shift in execution model, not the disappearance of the underlying capability.