How long does a Checkmarx to Corgea migration take?

Under two weeks for a full cutover, split into five phases: baseline bake-off (days 1-2), native source control connections (days 2-4), enforcement rules (days 4-6), developer and agent enablement (days 6-9), and reporting, governance, and decommission (days 9-14). The timeline is short because Corgea connects through API-native source control integrations rather than pipeline jobs, and because Auto-Discovery removes the tuning migration.

Do I need to port my Checkmarx presets and custom CxQL queries to Corgea?

Usually no. Corgea's Auto-Discovery studies your repository before the first scan, detects your frameworks and existing security controls, and generates project-specific policies from what it finds. Presets, custom CxQL queries, and false positive suppressions exist to compensate for a generic ruleset, so most of that configuration has no equivalent to port. The exception is break-build policy, which maps to Corgea blocking rules and should be ported deliberately.

Is there a coverage gap during the migration?

No. Checkmarx keeps running in non-blocking mode for the entire migration window. Corgea runs alongside it and only becomes the enforcing gate in step 3. If you want to stop, you turn Corgea blocking rules off and Checkmarx is still scanning, still reporting, and still enforcing. You archive Checkmarx at the end of the window, not the start.

Can I compare Corgea and Checkmarx on my own code before migrating?

Yes. Upload your most recent Checkmarx JSON report into Corgea against the same repository and commit, then run a Corgea scan on that commit. Both result sets sit side by side in the same interface, so the comparison is on your code rather than on a benchmark suite. Out of the box, Corgea surfaces 2x the true positive findings and 3x fewer false positives than legacy SAST.

What Checkmarx infrastructure goes away after migrating to Corgea?

Corgea connects to GitHub, GitLab, Azure DevOps, Bitbucket, and Harness Code through API-native integrations, so there is no scan job to maintain in each pipeline, no CxFlow deployment to operate, and no scan engines or agents to host and size. Scans are triggered by repository events or on a schedule.

How to Migrate from Checkmarx to Corgea in Under 2 Weeks

Replacing Checkmarx One, Checkmarx SAST, or CxSAST has a reputation for being a multi-quarter program. That reputation comes from the architecture, not from the work: a traditional SAST migration means re-plumbing every pipeline, re-hosting scan engines, and re-creating years of accumulated tuning in a new query language.

Corgea removes both of those workstreams. It connects to source control through API-native integrations, so there is no pipeline engineering, no scan agents to host, and no CxFlow to redeploy. And Auto-Discovery removes the tuning migration entirely, so you do not port presets, custom CxQL queries, or false positive suppressions.

What is left is five steps of real, concrete work that fits in under 14 days.

Before you start: rollback and coverage

Checkmarx keeps running, non-blocking, for the entire migration window. Corgea runs alongside it and only becomes the enforcing gate in step 3.

That gives you two things a security buyer needs. There is no coverage gap: at every point in the 14 days, at least one scanner is scanning every repository in scope. And rollback is a configuration change, not a project: disable Corgea blocking rules, and Checkmarx is still scanning, still reporting, and still gating exactly as it did before. You archive Checkmarx at the end of the window, and you drop the license at renewal, not before.

Step 1: Baseline the bake-off (Days 1-2)

Do not start with a new scan. Start with the Checkmarx results you already have, so the comparison is apples-to-apples on the same repository and the same commit.

Corgea ingests third-party scanner output directly, including Checkmarx JSON, Fortify FPR, and Coverity XML (upload docs). Generate the report from the Checkmarx CLI and push it into Corgea with the Corgea CLI:

# Generate a Checkmarx JSON report for the target repo
cx scan create --project-name juice-shop -s . --branch master \
  --scan-types sast --report-format json --output-name report

# Upload the Checkmarx findings into Corgea
corgea upload report.json --project-name juice-shop

Then scan the same commit with Corgea’s own AI SAST engine (corgea scan) so both result sets sit in the same interface against identical code.

Pick two or three repositories that represent your real portfolio, not your cleanest one: one high-traffic service, one legacy application with a large open finding count, one repository your developers already distrust the scanner on.

What you are measuring, per repository:

Confirmed true positives. Corgea surfaces 2x the true positive findings of legacy SAST out of the box.
False positive volume. Corgea produces 3x fewer false positives. Measured as a rate, Corgea’s true-positive rate is 77% against Checkmarx’s 35%.
Findings each tool missed. Both directions matter. Note anything Checkmarx flagged that Corgea did not, and take it to your Corgea contact rather than assuming a gap.

Two days is enough because the Checkmarx side of the comparison is a report you already have.

Step 2: Connect version control natively (Days 2-4)

This is the step that usually consumes a quarter, and it is the step that mostly disappears.

Corgea connects to GitHub (via the Corgea GitHub App), GitLab, Azure DevOps, Bitbucket, and Harness Code through the API, using an app install or a scoped access token. Corgea registers its own webhooks and scans on repository events. For repositories that are not event-driven, scheduled scans run on a cadence scoped by project, tag, or team.

Concretely, the following Checkmarx work items have no Corgea equivalent to build:

No scan step to add, version, and maintain in every pipeline definition.
No CxFlow deployment to host, configure, and keep patched.
No scan engines or engine pools to size, license, and queue against.
No pipeline credentials distributed to every build agent.

The work that remains is real but bounded: create the integration credential (a dedicated service user or service account is the recommendation on GitLab, Bitbucket, and Harness), decide which repositories Corgea can access, and confirm webhook delivery on a test pull request. Onboarding is per-organization, not per-pipeline, which is why this is a two-day task instead of a per-team rollout.

Step 3: Set enforcement rules, skip the tuning migration (Days 4-6)

This is where migration plans normally collapse. The instinct is to port the accumulated configuration: presets, custom queries, suppression lists, policy thresholds. Most of it should not come with you.

Checkmarx tuning exists to compensate for a generic ruleset that treats a Django monolith and a legacy PHP application identically. Corgea’s Auto-Discovery does that work before the first scan: it detects your languages, frameworks, and architecture, has an agent read the codebase for the security controls your developers already built (auth decorators, ORM usage, validators, middleware, WAF configuration), validates those patterns, and converts them into project-specific false-positive and fix policies. Learning then turns developer feedback, including false positive calls made in pull request comments, into reviewed policy so the same dismissal does not come back next scan.

That changes what you port:

Checkmarx artifact	Corgea equivalent	Port it?
Scan presets (Default, OWASP Top 10, custom preset trees)	Auto-Discovery generates per-project policy from your actual frameworks	No
Custom CxQL queries written to reduce noise	Auto-Discovery plus Learning	No
Custom CxQL queries encoding genuinely bespoke business logic	PolicyIQ policy or `corgea.yaml` in the repo, written in plain English	Only these
”Not Exploitable” / “Proposed Not Exploitable” suppressions	Auto-Discovery plus Learning; re-triage in Corgea rather than importing	No
Exclusion and file filter lists	File ignore rules (tests, `node_modules`, build output, generated code are excluded by default)	Only project-specific paths
Muted vulnerability categories	Per-project CWE filters, optionally scoped by glob	Only if still in scope
Break-build thresholds and policy failure conditions	Blocking rules by CWE and severity, scoped to projects or project tags; `corgea scan --fail` in CI	Yes

Break-build policy is the one row that needs deliberate porting, because it encodes a decision your organization already made. Create the blocking rules, then leave them inactive while Checkmarx is still the gate. Activate them at the end of this step and let Checkmarx continue in report-only mode.

Because of Auto-Discovery, policy customization is usually unnecessary at migration time. Run two weeks of scans before you decide you need a custom policy; most teams find the reason they wanted one has already been handled.

Step 4: Developer and agent enablement (Days 6-9)

Enforcement without developer tooling produces the same distrust you are migrating away from. Roll out three surfaces in parallel.

IDEs. The VS Code and Visual Studio 2022 extensions list findings in a sidebar, show the proposed diff and its explanation, and apply the fix in place.

Pull requests. Corgea Agent comments on findings in the PR diff and reads replies. A developer writes @Corgea false positive with reasoning, or @Corgea accept risk, or @Corgea fixed, and the status changes, the finding stops blocking the merge, and the reasoning feeds Learning. Triage happens in code review instead of in a separate queue. Scan-and-comment scope is controlled by PR rules in PolicyIQ.

Coding agents. The Corgea Agent Skill teaches Cursor, Claude Code, GitHub Copilot, and OpenAI Codex to drive the CLI: scan, list issues, inspect a finding, retrieve the fix, apply it. Install it with corgea skill install corgea --agent cursor --scope user. The MCP server adds read access to scans, issues, dependency data, and blocking rules for any MCP client. See developer experience for how these fit together.

Step 5: Reporting, governance, decommission (Days 9-14)

Replace the reporting and governance dependencies your Checkmarx deployment is currently carrying.

Ticketing. Connect Jira and create tickets from issue pages.
Export. SARIF 2.1.0, CSV, and PDF export for compliance evidence and downstream tooling.
Automation. Webhooks for scan.completed, issue.status_changed, and sla.violation into your SIEM or GRC pipeline.
Access. SAML SSO with group export, plus teams for project access at scale.
Accountability. SLA management for remediation and escalation windows per urgency, separately for SAST and SCA findings.
Trend integrity. Issue fingerprinting uses AST-based identity, so a finding survives reformatting and refactoring and your open/fixed/reopened counts stay honest across scans.

Then close out Checkmarx. Export the historical findings you are required to retain, archive the project data, remove the now-unused pipeline steps and CxFlow infrastructure, and let the license lapse at renewal. Do this last, once Corgea has been the enforcing gate for several days and your reporting no longer reads from Checkmarx.

Why this compresses to 14 days

Nothing here is effortless. There are five steps of genuine work: credentials, integration scope, enforcement decisions, developer rollout, and governance wiring. What is missing are the two workstreams that make Checkmarx migrations feel like platform projects: pipeline engineering and the tuning migration.

Corgea’s workflow is not a feature-by-feature reproduction of Checkmarx. It is a different shape: findings arrive in the pull request instead of a scan queue, triage happens in review instead of in a suppression database, and tuning is discovered from your code instead of authored in a query language. That is the argument for migrating, and it is also the reason the migration is short. The Corgea vs. Checkmarx comparison covers where the two platforms overlap and where they do not, and Checkmarx alternatives covers the wider shortlist if you are still evaluating.

Run the bake-off first

Do not take the numbers on trust, and do not commit to anything to test them. Upload your most recent Checkmarx JSON report into Corgea, run a Corgea scan on the same commit, and look at the delta on your own code: true positives found, false positives avoided, and what each tool missed.

Request a bake-off and see whether the comparison holds on your repositories. If it does not, you have lost two days. If it does, you have the whole cutover mapped and a renewal date to use.