You probably don't want to migrate a browser suite. You want to find out whether a different way of writing tests is worth it, without losing the coverage you have. So start alongside the tests you trust, and pick a narrow boundary.
Choose an adoption boundary
A sensible boundary might be the handful of browser flows your team still checks manually. Keep the existing framework for tests that already provide a reliable signal. That gives you evidence for or against adoption without turning the evaluation into a suite rewrite.
Compare like with like
Choose a useful existing flow or a repeated manual gap, and record its setup and expected outcomes. Different test data makes a comparison misleading, so run both with equivalent data. Then compare what it takes to understand a failure, and what it takes to maintain the test after a real UI change.
A migration can quietly remove assertions, so don't delete an old test until you've reviewed its replacement. A larger test count isn't more coverage, and requirement changes still need someone's time whichever tool you use.
What this looks like with Zerocheck
Zerocheck doesn't convert framework code. It drafts browser steps from a description or checklist, so describe the flow in the web app, inspect the drafted steps and save the test after reading its result.
Download YAML if you want it in your repository. That creates an independent copy, with no two-way sync: web tests are edited in Zerocheck, and repository tests are edited in your repository and shown read-only in the web app. Decide which copy your team maintains.
Keep API, email, mobile and cross-browser coverage in your existing tools, because Zerocheck doesn't cover them.