It's time to create a new migration and reflect the code changes to the database by taking advantage of the code-first approach we chose in Chapter 4, The Data Model.

It's worth noting that if we were using Entity Framework 6, we could entirely skip this step by implementing the auto-migration feature it used to have. Unfortunately, there's no such thing in EF core, so we must add our migrations manually.

Let's open a Powershell command prompt and go to our project's root folder, then write the following:

> dotnet ef migrations add "Identity" –o "DataMigrations"

A new migration will be added to the project. Right after that, we could choose to update our database...except it won't be a good idea. Applying the new migration will most likely cause some data loss or other consistency issues due to the fact that our ApplicationUser class experienced some major changes. Such a scenario is also clearly stated by the yellow message shown by the Powershell tool upon completing its given task:

Since we updated our DbSeeder class to support the new changes, the best thing we can do would be letting it re-populate our database accordingly. Unfortunately, we know perfectly well that as long as there are some existing users and items in the database tables, it won't even run. This leaves us with nothing but one solution: drop and recreate the database, so the DbSeeder will kick in and re-populate everything on the first run.

In order to do that, issue the following Powershell commands:

> dotnet ef database drop
> dotnet ef database update

We'll also have to hit Y to confirm the drop.

Once done, hit F5 and wait for the DbSeeder to kick in. After that, it will do its magic. We'll have an updated database with full AspNetCore.Identity support.