After testing out the new schema for review documents, we are ready to release it to production. The only problem is, not all of our teams are ready to adopt the updated schema. In this video, we will discuss the trade-offs and complexities associated with schema migrations, and how MongoDB makes them simple. An application schema will be updated and modified to support the natural evolution of apps and business needs. Transitioning from one schema to the next is known as schema migration and it is an essential part of the software development process. The database schema acts as a contract between database users. Migrating from one schema to the next typically requires significant coordination because all stakeholders need to be aware of and agree on the proposed changes. If stakeholders aren't on the same page, we might introduce breaking changes, including bugs, security, or compliance issues. Thankfully, MongoDB's flexible document model allows for frictionless schema migrations, supporting your organization's needs and simplifying the coordination requirements. This flexibility allows multiple schema versions to coexist in the same collection. Versioning is a common strategy to enable controlled migrations, where users can specify a version when they query the database, and developers can make changes to the next version while maintaining compatibility with the current one. Keep in mind that handling a large number of versions is challenging because it increases application complexity and creates technical debt. For this reason, you should limit the number of schema versions to the minimum required by your organization and use case. Leveraging the schema versioning pattern and schema validation allows you to smoothly transition from one version to the next. This ensures that we adhere to required business rules while maintaining backwards compatibility for migrations without downtime. Once we are ready to migrate to the new version of our schema, there are several strategies that we could use, including eager migration, where we make changes all at once; lazy migration, where changes are implemented as data is used; incremental migration, where we take small steps to implement changes; and predictive migration, where we update the schema based on predictions of how data will be used in the future. The best strategy ultimately depends on the needs of the business and the application. Let's apply this to our bookstore app. We are ready to release the new schema for review documents that includes a locale field and we want to make the field required from now on. However, our dotcom team needs to continue using the original schema so that they can complete their current sprint. We will add the locale field in all reviews eventually, but for now we can leverage the schema versioning pattern to allow the old version during the migration. But the question is, how do we enforce the schema if there is more than one version? A simple way to do this is using the oneOf keyword when we define the schema-validation rules for the reviews collection. But before we learn how this can be accomplished, let's look at the two schemas that we wish to use. The bookstore_reviews_default schema doesn't require any changes, but we need to implement the schema versioning pattern on the bookstore_reviews_international schema for any future versions of the schema that we wish to add to the reviews collection. Here, we've added the schema version field to the required array and to the properties object. We use the enum keyword to specify a list of allowed values for the field. This will help us control how many schema versions we want to support. Next, we define the validator document with the oneOf keyword. This requires the input document to be valid against exactly one of the included schemas but not both. We've also set additional properties to false in each of the underlying schemas, such that documents must completely conform to the required fields. Now we can supply schema_migration_validation as the validator document when we run the collMod command. And since we are moving to staging and production, we are setting the validation level to strict and the action to error. Great. Now, the locale field will be added to new review documents when they are added to the collection, and our old reviews can be lazily migrated-- or, in other words, our changes will be made as old documents from the reviews collection are used. This way, our dotcom team can keep using the default schema as we also release the newest version to support our French site. Let's recap what we've learned in this lesson. Transitioning from one schema to the next is known as schema migration, and it's an essential part of the software development process. You learned that you can leverage the schema versioning pattern to allow multiple valid schemas and enable controlled migrations. Finally, we walked through a schema migration scenario in our bookstore app. We had to enforce more than one version of a schema for the reviews collection. You learned how to use the schema validation feature with the oneOf keyword in the validation document to validate multiple document shapes. That's the last lesson for this unit. Next, we'll wrap things up in the conclusion.