1. Public API Contracts
This is your number one priority. Your public APIs—whether they serve a front-end application, mobile clients, or external partners—are the firmest promises your system makes. Freezing them means no new endpoints, no changing existing response structures,
and no altering request parameters. Why? Because any change here creates a moving target for the teams depending on you. The migration team needs a stable, predictable contract to build against. You can still fix bugs behind the API, but the interface itself must become immutable. Think of it as the foundation of a house; you don't start renovating the foundation while you're trying to add a second story.
2. Core Data Schemas and Models
Just as critical as your API contracts are your core data schemas. Before you begin migrating data or services, lock down the structure of your most important database tables and data models. Adding or altering columns in your `users`, `products`, or `orders` tables during a migration is a recipe for disaster. It leads to data corruption, broken ETL jobs, and rollback nightmares. A stable schema ensures that the data you extract from the old system will match the shape the new system expects. Any necessary schema changes should be part of the migration plan itself, not a random feature request that slips in mid-flight.
3. Authentication and Authorization Logic
Security code is not the place for improvisation, especially during a period of major architectural change. Your authentication (who is the user?) and authorization (what can they do?) systems must be completely frozen. Any changes to how tokens are generated, how permissions are checked, or how sessions are managed will introduce massive risk. A migration is already a prime target for security vulnerabilities to creep in as developers focus on functionality. By freezing your security layer, you create a known-good perimeter that you can then carefully migrate or integrate with the new system, one piece at a time.
4. Third-Party Dependency Versions
This is the silent killer of many engineering projects. An innocuous `npm install` or `bundle update` can pull in a minor or major version bump of a library that introduces subtle breaking changes. Before a migration, you must pin your dependencies. Every single one. This means specifying exact versions (e.g., `react: "18.2.0"`, not `"^18.2.0"`). This practice, known as version pinning, creates a repeatable and deterministic build environment. The last thing you want to be doing during a migration is debugging whether an issue is from your code, the new platform's code, or a third-party library that decided to change its behavior overnight.
5. The Build and Deployment Pipeline
Your CI/CD (Continuous Integration/Continuous Deployment) pipeline is the factory that assembles and ships your code. You can’t afford for the factory to change its processes while you’re trying to manage a complex product transition. Freeze your build scripts, testing configurations, and deployment workflows. The team needs to have absolute confidence that when they push a commit, it will be tested and deployed in the exact same way it was yesterday. This stability is crucial for quickly diagnosing issues. If a deployment fails, you'll know the problem is likely the code change itself, not a surprise update to your Docker image, test runner, or deployment script.
6. Critical User Workflows (For New Features)
Finally, communicate a feature freeze on your most critical, revenue-generating user paths. This doesn't mean you can't fix a bug in the checkout process. It means you absolutely should not be adding a new payment option or redesigning the login flow. By halting new feature development on these core journeys, you reduce the surface area for new bugs and allow the QA team to focus their regression testing efforts on the migration itself. This is often the hardest freeze to sell to product and business stakeholders, but it’s essential for de-risking the project. Frame it not as 'stopping work,' but as 'protecting the business' during a sensitive operation.
