Foundry Migration: Is Switching From Hardhat Worth It?

For the past two years, the migration calculus looked simple: Foundry's Rust-powered runtime ran test suites 10–20x faster than Hardhat's JavaScript-based stack, and that performance delta alone justified the switch for most teams above a certain project size. That math changed in June 2026. Hardhat 3 shipped stable with a Rust-powered Ethereum Development Runtime (EDR) that executes Solidity tests natively and closes the speed gap to roughly 2x. Teams that deferred migration in 2024 because their CI bill was already painful and their TypeScript-heavy scripts worked fine now face a different question: is the speed advantage alone worth the migration tax, or does the decision now hinge on architectural fit?

That is not a rhetorical question. With Hardhat 2 scheduled for end-of-life on June 1, 2027 (or earlier if the Hegota mainnet activates first), every team running Hardhat is on a forced decision timeline regardless. The question is no longer whether something has to change — it does — but which path the change takes: upgrade to Hardhat 3, migrate to Foundry, or run a hybrid setup that uses both runtimes against the same codebase.

The Performance Shift: Hardhat 3 and the Rust-Powered EDR

The headline metric driving the "switch to Foundry" narrative for the last four years was throughput. A Hardhat 2 test suite of 50 contracts would routinely complete in 18–25 seconds; Foundry's forge would finish the same suite in 2–4 seconds. On larger protocols with hundreds of invariant tests, the gap widened into minutes of CI time per run, and CI cost became a real line item in engineering budgets.

Hardhat 3's EDR — a Rust-based execution layer that replaces the JavaScript-heavy core of Hardhat 2 — fundamentally rewrites that trade-off. Foundry's forge still holds an edge, but the gap is now measured in a 2x factor rather than an order of magnitude. For most projects, this means the CI math that justified a migration in 2024 no longer applies. The bottleneck that pushed teams toward Foundry has been partially resolved at the runtime level.

In practice, this changes the conversation in two specific ways. First, teams that prioritized speed above all else — typically high-frequency DeFi protocols with large fuzzing suites — still benefit from Foundry, but the benefit is incremental rather than transformative. Second, teams that stayed on Hardhat because their TypeScript tooling, deployment scripts, and off-chain test harnesses were deeply integrated now have a defensible reason to upgrade in place rather than migrate.

Conversely, Hardhat 3 also brings native Solidity test support. Where Hardhat 2 required either external plugins or workarounds to execute Solidity-native tests, Hardhat 3 reads foundry.toml, resolves remappings.txt, and runs .t.sol files directly. The wall between the two ecosystems has thinned considerably.

The 10x performance argument that drove Foundry adoption in 2023 is no longer the deciding factor. Architecture is.

Foundry's Edge: Native Solidity Execution and Fuzzing

Even with EDR narrowing the speed gap, Foundry retains architectural advantages that have nothing to do with raw throughput. The toolkit — forge, cast, anvil, chisel — is built around a single principle: Solidity developers should write, test, and debug in Solidity, without the cognitive overhead of crossing a language boundary.

Forge executes tests directly in Solidity. There is no transpilation step, no JavaScript VM emulation, no TypeScript harness mediating between the test logic and the EVM. For developers who think in terms of contract state, msg.sender semantics, and storage layouts, this is closer to the metal than any JavaScript-based framework can offer.

The practical payoff shows up most clearly in two areas: fuzzing and invariant testing. Foundry's built-in fuzz runner can execute thousands of test cases with random inputs in seconds — a capability that, in the Hardhat 2 era, required either foundry-compatible plugins, custom TypeScript scripts, or third-party tools like Echidna. Foundry's invariant testing is similarly native: stateful properties are expressed in Solidity and continuously probed across random sequences of function calls, surfacing property violations that a hand-written test suite would miss.

Anvil, Foundry's local node, deserves separate mention. It forks mainnet state in a single command, supports state snapshots for deterministic test replay, and runs fast enough that complex integration tests — including flows that touch token-gated logic typical in NFT gaming and GameFi play-to-earn settlement architectures — feel trivial rather than heroic. Cast rounds out the toolkit as a command-line interface for chain queries and transactions, useful for scripting deployment verification and on-chain forensics without leaving the terminal.

The trade-off matrix here is straightforward: Foundry optimizes for Solidity-native purity and gives up ergonomic tooling for off-chain TypeScript workflows. Hardhat 3, with EDR, closes the speed gap while preserving TypeScript integration as a first-class citizen.

Market Trends and the Hardhat 2 EOL Clock

The adoption data tells a story independent of any individual team's preferences. Foundry's share of Ethereum-specific IDE usage grew from 1.6% in 2021 to 51.1% by late 2025. Over the same period, Hardhat's share fell from roughly 75% in 2022 to 32.9%. Foundry is no longer the challenger framework; it is the majority tool.

But Hardhat's installed base is not evaporating — it is shifting. Hardhat 3, which shipped as a beta in August 2025 and reached stable production readiness on June 15, 2026, is explicitly designed to retain the TypeScript-centric developer base while closing the architectural gaps that pushed early adopters toward Foundry. The Nomic Foundation's strategy is convergence, not competition.

The timeline pressure, however, is unambiguous. Hardhat 2 is scheduled for end-of-life on June 1, 2027, or earlier if the Hegota mainnet activates first. Hardhat 2 will not receive updates for hardforks past Glamsterdam. Teams still on Hardhat 2 are running on borrowed time — not because the tool will stop working, but because it will stop tracking protocol upgrades.

Hardhat 2's end-of-life is not a soft deadline. After June 1, 2027 — or Hegota activation, whichever comes first — hardfork tracking stops at Glamsterdam.

For teams that have not yet upgraded, the realistic decision paths are:

1. Upgrade to Hardhat 3 and retain the TypeScript workflow.

2. Migrate to Foundry and accept the Solidity-native paradigm shift.

3. Maintain a hybrid setup — Hardhat 3 for deployment scripts and TypeScript tests, Foundry for fuzzing and invariant suites.

Each path carries a different cost profile. Path 1 is the lowest-friction option for teams with significant TypeScript investment. Path 2 requires rewriting scripts and adapting to the foundry.toml / remappings model. Path 3 is pragmatic for large codebases but introduces tooling complexity that has to be maintained indefinitely.

The TypeScript Question: When Integration Outweighs Purity

The architectural fork that now defines the decision is not speed — it is the off-chain footprint. Hardhat 3 preserves TypeScript as a first-class language for deployment scripts, integration tests, and tooling around the smart contract layer. Foundry treats TypeScript as a deployment-time concern rather than a test-time one.

For teams whose off-chain code is substantial — bots, indexers, off-chain computation layers that interact with contracts, complex deployment pipelines that coordinate multiple chains — the TypeScript integration in Hardhat 3 is a meaningful advantage. The same test harness that exercises contract behavior can also mock external APIs, simulate oracle responses, and coordinate multi-contract setups without crossing language boundaries.

Conversely, teams whose off-chain surface is minimal — a deploy script, a frontend that consumes ABIs, perhaps a basic subgraph — gain little from Hardhat's TypeScript layer. For these teams, Foundry's pure Solidity model reduces complexity: one language for the test layer, one configuration file, one toolchain.

The trade-off matrix below summarizes the architectural decision:

Migration Logistics: Compatibility and the Node.js Floor

For teams leaning toward migration, the practical path is shorter than it was two years ago. Hardhat 3 provides native compatibility with Foundry: it can run Solidity tests, parse foundry.toml, and resolve remappings.txt files. This means a team can incrementally migrate tests from Hardhat's TypeScript harness into Foundry's Solidity-native format without breaking the existing setup.

The Node.js floor is the most concrete logistical constraint. Hardhat 3 requires Node.js v22.13.0 or later. Teams running older Node versions on CI infrastructure will need to update their base images before the upgrade. Foundry, by contrast, ships as a single static binary with no Node dependency, which simplifies CI configuration and removes a class of version-management issues entirely.

The migration typically follows this sequence:

1. Install Foundry via foundryup and verify forge, cast, anvil, and chisel are available.

2. Translate the Hardhat config into foundry.toml, including remappings for OpenZeppelin and any custom dependencies.

3. Port .js test files into .t.sol files, preserving the test names and the contracts under test.

4. Run forge test against the migrated suite and diff the results against the Hardhat output.

5. Decommission the TypeScript tests for the migrated contracts; retain Hardhat only for deployment scripts and any genuinely off-chain tests.

6. Update CI to run both forge test and the remaining Hardhat tasks during the transition window.

Teams that have already structured their tests with clear contract boundaries — one test file per contract, minimal cross-contract fixtures — report migrations completing in days. Monolithic test suites with deep cross-cutting fixtures take longer, but the Hardhat 3 compatibility layer lets teams migrate incrementally rather than all at once.

The Bottom Line

The question "is migrating from Hardhat to Foundry worth it?" no longer has a universal answer. In 2023, the answer defaulted to yes for any non-trivial project because the performance gap was decisive. In 2026, with Hardhat 3's EDR closing the speed gap to roughly 2x and adding native Solidity test support, the answer depends on architectural fit.

For teams with substantial TypeScript investment in deployment scripts, off-chain tooling, or integration tests, upgrading to Hardhat 3 is the lower-friction path. The speed penalty is real but tolerable, the TypeScript layer is preserved, and the EOL clock is satisfied. Migrating to Foundry under these conditions trades away a working toolchain for a marginal speed gain.

For teams with minimal off-chain surface, large fuzzing or invariant requirements, or a desire for a unified Solidity-native workflow, Foundry remains the stronger choice. The performance advantage, even at 2x, compounds across large test suites and CI runs. The native fuzzing and invariant tooling is more mature than Hardhat 3's equivalents, and the absence of a Node.js dependency simplifies infrastructure.

The Hardhat 2 EOL forces a decision regardless. The realistic options are upgrade-in-place, migrate, or hybrid. The hybrid path is viable for large codebases but introduces long-term tooling complexity. For most teams, the cleanest path is either Hardhat 3 or Foundry — and the deciding factor is now TypeScript integration depth, not raw speed.