Zipper Tools

Pydantic Migration Guides

How to replace @root_validator(pre=True) with @model_validator(mode="before")

Migrate the supported pre root-validator subset in Pydantic v2 and keep the rest out of the automatic path.

Start here

The safe first move

For supported pre=True root validators with the simple (cls, values) signature, the v2 replacement is @model_validator(mode="before").

Stop before automation when: Post root validators. root_validator kwargs outside pre=True.

Target shape

from pydantic import BaseModel, model_validator

class Payload(BaseModel):
    name: str

    @model_validator(mode="before")
    def normalize_input(cls, values):
        return values

Repo fit check

Want to know if your repo has this pattern?

Run the matching scanner locally first. Read the free findings and manual alternatives; consider paid cleanup only if supported patterns repeat enough to justify the price.

  • Local scan; no repository upload.
  • Supported findings are separated from manual-review findings.
  • Buy only when the repeated pattern is worth automating.
Run the Pydantic scan first View example report See when to buy 
Example scan summary
supported_findings: 38
manual_review_findings: 6
files_uploaded: 0
confidence: reviewable

Why this page exists

How to replace @root_validator(pre=True) with @model_validator(mode="before")

The safe root-validator case is pre=True with the simple (cls, values) classmethod signature.

Direct answer

What changes

For supported pre=True root validators with the simple (cls, values) signature, the v2 replacement is @model_validator(mode="before").

Example

Before and after

Before

from pydantic import BaseModel, root_validator

class Payload(BaseModel):
    name: str

    @root_validator(pre=True)
    def normalize_input(cls, values):
        return values

After

from pydantic import BaseModel, model_validator

class Payload(BaseModel):
    name: str

    @model_validator(mode="before")
    def normalize_input(cls, values):
        return values

Decision path

If this repeats across the repo, open the evaluation pages next.

The cleanup pack is strongest when the repo still uses direct pydantic imports and a clean validator/settings/config subset.

  • The repo has direct pydantic or pydantic.v1 imports, BaseSettings usage, safe Config blocks, or simple validators.
  • The migration pain is repetitive v1-to-v2 cleanup, not a custom semantic rewrite.
  • If the scan output is ambiguous, review its findings and upstream guidance. Do not buy expecting unsupported cases to be resolved.

Typical symptoms

  • Repos still use pre=True root validators from Pydantic v1.
  • Teams want the clean decorator migration handled automatically.
  • Reviewers need a stop signal before post validators or custom signatures.

What the product covers

  • pre=True root_validator to model_validator(mode="before") rewrites.
  • Reporting for exactly where the supported root-validator subset appears.
  • Cross-links to the post root-validator manual bucket.

Manual-review boundary

  • Post root validators.
  • root_validator kwargs outside pre=True.
  • Signatures more complex than exact (cls, values).

Keep the migration narrow

Use the exact-problem guides as a triage layer, then decide whether the repo is inside the supported subset.

FAQ

Fast answers before you decide

What is the safest fix for root_validator pre model_validator pydantic v2?

For supported pre=True root validators with the simple (cls, values) signature, the v2 replacement is @model_validator(mode="before").

Can root_validator pre model_validator pydantic v2 be automated?

Automate only the supported subset: pre=True root_validator to model_validator(mode="before") rewrites. Reporting for exactly where the supported root-validator subset appears. Cross-links to the post root-validator manual bucket. Keep these cases in manual review: Post root validators. root_validator kwargs outside pre=True. Signatures more complex than exact (cls, values).

When should I buy Pydantic v1 to v2 Migration Cleanup Pack?

Use Pydantic v1 to v2 Migration Cleanup Pack only when this pattern repeats across enough files that manual cleanup is still costly. Use the free report and upstream guide to evaluate fit. Buy only if repeated supported edits justify the price; no paid assessment is required.

Purchase fit

Choose the lowest-risk next step.

One matching page is not enough by itself. Run the local scan, then buy only when the same supported pattern appears often enough to matter.

Buy if

  • The repo has direct pydantic or pydantic.v1 imports, BaseSettings usage, safe Config blocks, or simple validators.
  • The migration pain is repetitive v1-to-v2 cleanup, not a custom semantic rewrite.
  • The team accepts manual-review findings for alias-heavy imports and signature-heavy validators.

What the workflow includes

  • Installable local CLI workflow, not a hosted black box.
  • Supported validator, settings, import, and config rewrites.
  • Demo report, public proof, coverage notes, rollback checklist, and buyer terms.

Before checkout

  • Stripe Checkout handles secure payment and receipts.
  • Download your purchased ZIP after payment.
  • Runs locally; no hosted API, repo upload, or production credentials needed.
  • The free report includes the evidence needed to evaluate fit. Paid summary and template add-ons are optional.
  • 14-day refund review for published-scope or delivery mismatches.
Run the Pydantic scan first

Explore the details