# Customizing migrations (Prisma ORM v7) (/docs/orm/v7/prisma-migrate/workflows/customizing-migrations)

> For the complete Prisma documentation index, see [llms.txt](https://www.prisma.io/docs/llms.txt). A markdown version of any docs page is available by appending `.md` to its URL.

How to edit a migration file before applying it to avoid data loss in production.

Location: ORM > v7 > Prisma Migrate > Workflows > Customizing migrations

In some scenarios, you need to edit a migration file before you apply it. For example, to [change the direction of a 1-1 relation](#example-change-the-direction-of-a-1-1-relation) (moving the foreign key from one side to another) without data loss, you need to move data as part of the migration - this SQL is not part of the default migration, and must be written by hand.

This guide explains how to edit migration files and gives some examples of use cases where you may want to do this.

## How to edit a migration file [#how-to-edit-a-migration-file]

To edit a migration file before applying it, the general procedure is the following:

* Make a schema change that requires custom SQL (for example, to preserve existing data)
* Create a draft migration using:

  

#### bun

```bash
bunx prisma migrate dev --create-only
```

#### pnpm

```bash
pnpm prisma migrate dev --create-only
```

#### yarn

```bash
yarn prisma migrate dev --create-only
```

#### npm

```bash
npx prisma migrate dev --create-only
```

* Modify the generated SQL file.
* Apply the modified SQL by running:

  

#### bun

```bash
bunx prisma migrate dev
```

#### pnpm

```bash
pnpm prisma migrate dev
```

#### yarn

```bash
yarn prisma migrate dev
```

#### npm

```bash
npx prisma migrate dev
```

### Example: Rename a field [#example-rename-a-field]

By default, renaming a field in the schema results in a migration that will:

* `CREATE` a new column (for example, `fullname`)
* `DROP` the existing column (for example, `name`) and the data in that column

To actually **rename** a field and avoid data loss when you run the migration in production, you need to modify the generated migration SQL before applying it to the database. Consider the following schema fragment - the `biograpy` field is spelled wrong.

```prisma highlight=3;normal; title="schema.prisma"
model Profile {
  id       Int    @id @default(autoincrement())
  biograpy String // [!code highlight]
  userId   Int    @unique
  user     User   @relation(fields: [userId], references: [id])
}
```

To rename the `biograpy` field to `biography`:

Rename the field in the schema:

```prisma highlight=3;delete|4;add; title="schema.prisma
model Profile {
  id        Int    @id @default(autoincrement())
  biograpy  String // [!code --]
  biography String // [!code ++]
  userId    Int    @unique
  user      User   @relation(fields: [userId], references: [id])
}
```

* Run the following command to create a **draft migration** that you can edit before applying to the database:

  

#### bun

```bash
bunx prisma migrate dev --name rename-migration --create-only
```

#### pnpm

```bash
pnpm prisma migrate dev --name rename-migration --create-only
```

#### yarn

```bash
yarn prisma migrate dev --name rename-migration --create-only
```

#### npm

```bash
npx prisma migrate dev --name rename-migration --create-only
```

* Edit the draft migration as shown, changing `DROP` / `DELETE` to a single `RENAME COLUMN`:

  

#### Before

```sql title="migration.sql" 
ALTER TABLE "Profile" DROP COLUMN "biograpy",
ADD COLUMN  "biography" TEXT NOT NULL;
```

#### After

```sql title="migration.sql" 
ALTER TABLE "Profile"
RENAME COLUMN "biograpy" TO "biography"
```

* Save and apply the migration:

  

#### bun

```bash
bunx prisma migrate dev
```

#### pnpm

```bash
pnpm prisma migrate dev
```

#### yarn

```bash
yarn prisma migrate dev
```

#### npm

```bash
npx prisma migrate dev
```

You can use the same technique to rename a `model` - edit the generated SQL to *rename* the table rather than drop and re-create it.

### Example: Use the expand and contract pattern to evolve the schema without downtime [#example-use-the-expand-and-contract-pattern-to-evolve-the-schema-without-downtime]

Making schema changes to existing fields, e.g., renaming a field can lead to downtime. It happens in the time frame between applying a migration that modifies an existing field, and deploying a new version of the application code which uses the modified field.

You can prevent downtime by breaking down the steps required to alter a field into a series of discrete steps designed to introduce the change gradually. This pattern is known as the *expand and contract pattern*.

The pattern involves two components: your application code accessing the database and the database schema you intend to alter.

With the *expand and contract* pattern, renaming the field `bio` to `biography` would look as follows with Prisma:

* Add the new `biography` field to your Prisma schema and create a migration

```prisma highlight=4;add; title="schema.prisma"
model Profile {
 id        Int    @id @default(autoincrement())
 bio       String
 biography String // [!code ++]
 userId    Int    @unique
 user      User   @relation(fields: [userId], references: [id])
}
```

* *Expand*: update the application code and write to both the `bio` and `biography` fields, but continue reading from the `bio` field, and deploy the code
* Create an empty migration and copy existing data from the `bio` to the `biography` field

  

#### bun

```bash
bunx prisma migrate dev --name copy_biography --create-only
```

#### pnpm

```bash
pnpm prisma migrate dev --name copy_biography --create-only
```

#### yarn

```bash
yarn prisma migrate dev --name copy_biography --create-only
```

#### npm

```bash
npx prisma migrate dev --name copy_biography --create-only
```

```sql title="migration.sql"
UPDATE "Profile" SET biography = bio;
```

4. Verify the integrity of the `biography` field in the database
5. Update application code to **read** from the new `biography` field
6. Update application code to **stop writing** to the `bio` field
7. *Contract*: remove the `bio` from the Prisma schema, and create a migration to remove the `bio` field

```prisma highlight=3;delete; title="schema.prisma"
model Profile {
 id        Int    @id @default(autoincrement())
 bio       String // [!code --]
 biography String
 userId    Int    @unique
 user      User   @relation(fields: [userId], references: [id])
}
```

  

#### bun

```bash
bunx prisma migrate dev --name remove_bio
```

#### pnpm

```bash
pnpm prisma migrate dev --name remove_bio
```

#### yarn

```bash
yarn prisma migrate dev --name remove_bio
```

#### npm

```bash
npx prisma migrate dev --name remove_bio
```

By using this approach, you avoid potential downtime that altering existing fields that are used in the application code are prone to, and reduce the amount of coordination required between applying the migration and deploying the updated application code.

Note that this pattern is applicable in any situation involving a change to a column that has data and is in use by the application code. Examples include combining two fields into one, or transforming a `1:n` relation to a `m:n` relation.

To learn more, check out the Data Guide article on [the expand and contract pattern](https://www.prisma.io/dataguide/types/relational/expand-and-contract-pattern)

### Example: Change the direction of a 1-1 relation [#example-change-the-direction-of-a-1-1-relation]

To change the direction of a 1-1 relation:

* Make the change in the schema:

```prisma title="schema.prisma"
model User {
 id        Int      @id @default(autoincrement())
 name      String
 posts     Post[]
 profile   Profile? @relation(fields: [profileId], references: [id])
 profileId Int      @unique
}

model Profile {
 id        Int    @id @default(autoincrement())
 biography String
 user      User
}
```

* Run the following command to create a **draft migration** that you can edit before applying to the database:

  

#### bun

```bash
bunx prisma migrate dev --name rename-migration --create-only
```

#### pnpm

```bash
pnpm prisma migrate dev --name rename-migration --create-only
```

#### yarn

```bash
yarn prisma migrate dev --name rename-migration --create-only
```

#### npm

```bash
npx prisma migrate dev --name rename-migration --create-only
```

```text
⚠️  There will be data loss when applying the migration:

• The migration will add a unique constraint covering the columns `[profileId]` on the table `User`. If there are existing duplicate values, the migration will fail.
```

* Edit the draft migration as shown:

  

#### Before

```sql title="migration" 
-- DropForeignKey
ALTER TABLE "Profile" DROP CONSTRAINT "Profile_userId_fkey";

-- DropIndex
DROP INDEX "Profile_userId_unique";

-- AlterTable
ALTER TABLE "Profile" DROP COLUMN "userId";

-- AlterTable
ALTER TABLE "User" ADD COLUMN     "profileId" INTEGER NOT NULL;

-- CreateIndex
CREATE UNIQUE INDEX "User_profileId_unique" ON "User"("profileId");

-- AddForeignKey
ALTER TABLE "User" ADD FOREIGN KEY ("profileId") REFERENCES "Profile"("id") ON DELETE CASCADE ON UPDATE CASCADE;
```

#### After

```sql title="migration" 
-- DropForeignKey
ALTER TABLE "Profile" DROP CONSTRAINT "Profile_userId_fkey";

-- DropIndex
DROP INDEX "Profile_userId_unique";

-- AlterTable
ALTER TABLE "User" ADD COLUMN "profileId" INTEGER;

UPDATE "User"
SET "profileId" = "Profile".id
FROM "Profile"
WHERE "User".id = "Profile"."userId";

ALTER TABLE "User" ALTER COLUMN "profileId" SET NOT NULL;

-- AlterTable
ALTER TABLE "Profile" DROP COLUMN "userId";

-- CreateIndex
CREATE UNIQUE INDEX "User_profileId_unique" ON "User"("profileId");

-- AddForeignKey
ALTER TABLE "User" ADD FOREIGN KEY ("profileId") REFERENCES "Profile"("id") ON DELETE CASCADE ON UPDATE CASCADE;
```

* Save and apply the migration:

  

#### bun

```bash
bunx prisma migrate dev
```

#### pnpm

```bash
pnpm prisma migrate dev
```

#### yarn

```bash
yarn prisma migrate dev
```

#### npm

```bash
npx prisma migrate dev
```

## Related pages

- [`Baselining a database`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/baselining): How to initialize a migration history for an existing database that contains important data.
- [`Development and production`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/development-and-production): How to use Prisma Migrate commands in development and production environments
- [`Generating down migrations`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/generating-down-migrations): How to generate a down migration SQL file that reverses a given migration file
- [`Native database functions`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/native-database-functions): How to enable PostgreSQL native database functions for projects that use Prisma Migrate.
- [`Native database types`](https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/native-database-types): Native database types