Introduction

This message usually appears when code or dependencies expect the old standalone keras package while the environment is built around TensorFlow 2.x. The practical fix is normally to migrate imports and usage to tf.keras; downgrading to TensorFlow 1.14 only makes sense when you are forced to keep a genuinely legacy codebase unchanged.

Why the mismatch happens

Historically, Keras existed both as:

• a standalone package: keras
• the TensorFlow-integrated API: tf.keras

TensorFlow 2.x standardized on tf.keras as the supported high-level API. Older projects that mix standalone Keras with TensorFlow-specific assumptions can therefore run into version conflicts, missing symbols, or behavior differences.

So the warning is really saying: "your current Keras package and your TensorFlow runtime do not belong to the same generation."

Prefer migrating to tf.keras

For most projects, the better path is to replace standalone Keras imports with TensorFlow-native ones.

Old style:

from keras.models import Sequential
from keras.layers import Dense

Recommended TensorFlow 2 style:

from tensorflow.keras.models import Sequential
from tensorflow.keras.layers import Dense

A minimal model becomes:

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Dense(32, activation="relu", input_shape=(10,)),
5    tf.keras.layers.Dense(1, activation="sigmoid"),
6])
7
8model.compile(optimizer="adam", loss="binary_crossentropy")

This keeps the model aligned with eager execution, modern saving formats, distribution features, and the TensorFlow 2 training workflow.

When downgrading still makes sense

Downgrading to TensorFlow 1.14 is only reasonable if you must preserve a legacy project that depends on:

• old standalone Keras behavior
• TensorFlow 1 graph execution patterns
• APIs that were removed or changed substantially

That is a compatibility strategy, not a long-term development strategy. It can be valid for frozen research code or old production systems, but it usually increases maintenance cost.

If you go that route, isolate it in a dedicated virtual environment or container so the legacy stack does not contaminate newer work.

Migration is more than import replacement

Changing imports is often enough for simple models, but some projects need more:

• replace fit_generator with fit where applicable
• update custom layers or callbacks to TensorFlow 2 idioms
• remove graph-session patterns such as manual session management
• review model save and load code

A staged migration works best:

1. switch imports to tf.keras
2. run tests
3. fix deprecated training or serialization patterns
4. verify saved-model behavior

That is much safer than doing a one-shot rewrite with no validation.

Common Pitfalls

The biggest mistake is mixing keras and tf.keras imports in the same project. That can create confusing type mismatches and runtime behavior that is hard to debug.

Another mistake is downgrading TensorFlow just to avoid a small import migration. That locks the project into older tooling when a cleaner modern path may already be available.

Developers also underestimate hidden migration points such as custom layers, callbacks, and model serialization formats. Imports may change quickly while edge cases take longer.

Finally, do not assume a legacy tutorial using standalone Keras maps directly onto a TensorFlow 2 environment without any changes.

If you truly must keep the legacy stack, isolate it in its own pinned environment or container. That prevents old dependencies from colliding with modern TensorFlow work elsewhere on the machine.

Summary

• TensorFlow 2.x is designed around tf.keras, not the older standalone Keras stack.
• The preferred fix is usually to migrate imports and usage to tf.keras.
• Downgrading to TensorFlow 1.14 is mainly for true legacy compatibility scenarios.
• Avoid mixing keras and tf.keras in one codebase.
• Treat migration as a small compatibility project, not just a one-line import change.