Migrate from Postman to Hoppscotch

Migrate from Postman to Hoppscotch: what the move involves

Teams usually look at this move after Postman's March 2026 plan change, which limited the Free plan to one user who cannot create a team, or after a data residency or lock-in review. The short answer is that collections and environments can be imported into a self-hosted Hoppscotch instance, and the real work is team setup, rewriting Postman scripts and planning the cutover. The importer documents Postman collections and environments, and self-hosted editions accept imports of up to 50 MB, compared with 10 MB on Hoppscotch Cloud. Confirm that your largest export fits that limit before you start.

The work usually falls to platform or security engineering, working with the API owners who know what each collection is for. The choice between Hoppscotch Community Edition and Enterprise Edition shapes the setup. Community Edition is free and open source, and your team installs, administers and upgrades it, and it signs users in through the Email, GitHub, Google and Microsoft OAuth providers you configure, with SMTP settings for email. Enterprise Edition adds SAML-based SSO, OpenID Connect, SCIM provisioning and audit logs under a license key. If your identity provider requires SAML or SCIM, confirm that requirement with your identity team before you choose the edition.

Effort depends on three things: how many collections and environments you are moving, how many pre-request and test scripts use Postman-specific functions, and what sign-in model your organization requires. Scripts are the item most likely to need manual rewriting, so inventory them first and test a few representative collections end to end. Plan the cutover in stages, keep Postman exports in a controlled location until the team has verified results, and decide early how secrets such as tokens will be stored, since they should not be copied into shared collections. Ask any implementation partner for a written scope that lists collections, scripts, identity integration and cutover steps.

Which Postman capabilities map to Hoppscotch and which need rework

This table maps the main Postman capabilities to Hoppscotch Community Edition and, where noted, Hoppscotch Enterprise Edition. Each row is marked clean, needs rework or gap, so you can scope translation work before you start the migration. Treat Postman-specific scripts and cloud-only features as items to confirm in a pilot, not as assumptions.

Postman capability	Hoppscotch fit	Status	What to check
Collections (JSON export)	Imported through the Postman importer, which accepts collections from Postman	Clean	Confirm folder structure, auth settings and request bodies after import
Environments	Imported from Postman alongside collections	Clean	Re-enter any secret values, since secrets should not be relied on to transfer
Shared team workspaces	Team workspaces in Community Edition, stored in your PostgreSQL database	Needs rework	Recreate team structure and role assignments by hand on the self-hosted instance
OAuth sign-in to the app	Email, GitHub, Google and Microsoft providers configured by the administrator	Needs rework	Register each OAuth client and set SMTP for email before inviting users
OpenAPI import	Collections can be created from OpenAPI specifications	Clean	Compare generated requests against the spec for missing examples or auth
Pre-request and test scripts	Scripts use Hoppscotch's own API, so Postman pm.* calls must be rewritten	Needs rework	Translate each script manually and rerun every test to confirm results
Postman cloud-only features (mock servers, monitors, AI credits)	No equivalent inside the Community Edition client	Gap	Plan replacements separately, such as self-hosted mocks or CI runs
CLI test runs (Newman or Postman CLI)	Hoppscotch CLI with hopp test, marked alpha, can write JUnit XML	Needs rework	Update CI scripts and confirm the alpha CLI meets your pipeline needs
SAML SSO and SCIM provisioning	Available only in the paid Enterprise Edition with a license key	Gap	Community Edition does not provide these, so confirm the need before choosing an edition

How to sequence the Postman to Hoppscotch cutover

This sequence moves Postman collections and environments into a self-hosted Hoppscotch instance in controlled stages, so the team can confirm each import before anyone relies on it. Each step ends with a written output that gates the next one.

Inventory collections, environments and dependencies
The API owner or lead developer lists every Postman collection, environment, global variable and mock or monitor that the team depends on, along with its owner and the services it calls. Mark each item as active, archived or duplicate, and flag any collection that holds credentials, tokens or customer test data. The output is a written inventory list that the team signs off before any export starts. It is complete when every active collection has an owner and a named target workspace in the new instance.
Export collections and environments from Postman
A user with the right access exports each collection in the Postman Collection v2 or v2.1 JSON format and exports the environments the team uses. Store the files in a restricted location, not in Git and not in a shared drive, because they can contain embedded secrets. Confirm what your plan and role allow, since bulk export is governed by Postman account rules that your admin should check. The output is a labeled folder of export files that matches the inventory one to one.
Stand up a self-hosted pilot instance
The platform team deploys Hoppscotch Community Edition in your own infrastructure with PostgreSQL set through the database connection setting, and configures sign-in with the OAuth providers your organization approves plus SMTP for email. Check the prerequisites and install guidance for the version you choose before deploying. The output is a running pilot instance reachable only by the pilot group, with a short record of the configuration and the version deployed.
Run a pilot import and log the results
One engineer imports a single representative collection and its environment through the Postman importer, then records the result for each request, folder, variable and script. Use an illustrative collection with a few requests, auth and pre-request scripts, and note which script constructs did not carry over. Confirm that the import size limit for self-hosted editions covers your largest export before you start, and split any file that exceeds it. The output is a verified import log, reviewed by a second engineer, that lists every item that needs manual rework.
Rewrite scripts and secrets in the pilot
The developers who own the pilot collection rewrite Postman scripts that use the pm object into Hoppscotch's script syntax and move credentials out of plain variables into environment values with restricted access. Test each rewritten script by sending the request and comparing the response against the original Postman result. The output is a short rewrite record that maps each original script to its replacement, along with a list of secrets that were moved and where they now live.
Run both clients against the same endpoints
For an agreed period, engineers send the same requests from Postman and from the pilot Hoppscotch instance against non-production endpoints, and compare status codes, response bodies and test outcomes. Where you run collections in CI, run the Hoppscotch CLI with hopp test alongside the existing pipeline and compare reports. Record each mismatch with a cause and a fix. The output is a parallel-run results sheet with zero open mismatches on the endpoints the team relies on.
Cut over teams and set a decommission checklist
Team leads move each team to its Hoppscotch workspace in the order set during inventory, and the platform team confirms that OAuth sign-in and workspace roles work for each group. Before revoking Postman access, export a final copy of every collection, store it in your retention location, and confirm that no pipeline still calls Newman or the Postman CLI. The output is a signed sign-off checklist per team, plus a record of the final archive and the date Postman access was removed.

What data moves, what stays behind and what to rebuild

Postman collections and environments move into Hoppscotch through its importer, but account-level data, scripts and CI integrations need separate work. The cards below separate what imports cleanly from what you must confirm, export manually or rebuild before cutover.

Collection JSON export path

Export each collection in Postman Collection v2 or v2.1 JSON, the interchange format Hoppscotch's importer reads. Export one collection at a time for a pilot, then compare request counts, folder structure and auth settings after import. Confirm the current export steps in Postman's documentation, since menu labels change between plan types.

Environment import

Hoppscotch's importer accepts Postman environments alongside collections, so variables such as base URLs can move with the requests. Check that every variable resolves after import, and review which values are secrets. Environment files often hold tokens, so store them in the self-hosted instance and keep copies out of Git.

Import size limit

A self-hosted Hoppscotch instance accepts collection imports up to 50 MB, compared with 10 MB on Hoppscotch Cloud. Large collections with embedded example responses or file bodies can exceed the Cloud limit, so self-hosting also removes that constraint for big exports. Split oversized exports by folder if an import fails.

OpenAPI and Insomnia sources

The importer also creates collections from OpenAPI specifications and from Insomnia exports. If your team keeps an OpenAPI file as the source of truth, importing it may produce a cleaner collection than the Postman export. Compare both imports and decide which one the team will maintain going forward.

Account-wide exports

Bulk exports covering the whole Postman account are an admin action, not something individual users can run. Ask a Postman team admin to start the export and confirm the download window, file format and which workspaces are included. Confirm the exact steps in Postman's documentation before planning the cutover date.

Scripts and CI runs to rebuild

Pre-request and test scripts written in Postman's JavaScript API do not run unchanged in Hoppscotch and must be rewritten. Existing CI pipelines that call Newman or the Postman CLI need new jobs using the Hoppscotch CLI, hopp test, which is alpha and needs Node.js 22 or later. Plan these as separate work items with their own testing.

How the migration changes for a solo user, a small team or a regulated organization

A single user moving personal collections has the simplest path. Postman's Free plan now allows one user, so the main question is whether personal collections should stay in Postman's cloud or move to a tool the user controls. Hoppscotch can be used in the browser or as a desktop app, and a personal collection can be imported from a Postman export without a team workspace or a server. Offline-only Bruno is another option for a single user who wants files on the laptop. The steps below cover the solo path.

Export first: Export each collection and environment as JSON from Postman before changing anything, and keep a copy outside the migration.
Import into a personal workspace: Use the Postman importer to load collections and environments, then send a test request from each collection to confirm headers and variables came across.
Skip the server: A personal migration does not need a self-hosted instance, a PostgreSQL database or SMTP settings.
Check secrets: Tokens and passwords saved in environments move with the file, so remove them from exported copies before sharing or committing anything.
Plan for scripts: Pre-request and test scripts often use Postman-specific objects, so review them after import.

Check that every imported environment variable resolves before deleting anything in Postman.

Rewriting Postman scripts for Hoppscotch

Pre-request scripts, test scripts, environment variable references and collection-level logic must be reviewed and rewritten against Hoppscotch's scripting model before cutover. A successful import of a Postman collection does not guarantee script parity: the request structure may arrive intact while the JavaScript that sets variables, chains requests, or asserts on responses behaves differently or does not run at all. Treat the imported scripts as a draft that needs review, not as working code. Start with a script inventory. For every collection, folder and request, record where each pre-request script, test script and variable reference lives, which Postman objects it reads or writes (environment variables, collection variables, global variables), and which other requests depend on values it sets. Include the scripts that run at folder and collection level, since those often carry authentication or signing logic that every request inherits. A spreadsheet with one row per script is enough for most teams, and it gives reviewers a list to tick off.

Then run a test-by-test comparison before cutover. Execute each Postman test against the same endpoints and environment in Hoppscotch, and record whether the assertion passes, fails or is skipped, and why. Pay particular attention to tests that depend on response timing, cookies, redirects or chained variables, because these are where translation most often changes results. Keep the Postman results as the baseline, and do not retire the original collection until every test has a documented outcome. Confirm the current script APIs, object names and supported test functions in the Hoppscotch documentation for your release, since they change between versions. Check the same for the Hoppscotch CLI if the team runs tests in CI, because a script that passes in the app may still need adjustment for hopp test. Assign ownership for the rewrites and the sign-off, and plan time for the rework that the inventory uncovers.

What drives the cost and duration of this migration

The cost of moving from Postman to a self-hosted Hoppscotch instance splits into one-time migration work and recurring hosting and staff time. The cards below cover what sizes each part, which parts are fixed by your choices, and what to put in writing before work starts.

Collection and environment volume

The number of collections, environments and requests sets the import and review effort. Hoppscotch's importer accepts Postman collections and environments, and self-hosted editions allow imports up to 50 MB, so check export sizes early. Large exports with attached files or many variables take longer to verify. Ask the implementer to inventory collections, environments and folders before quoting, and to flag any that exceed the limit so they can be split.

Pre-request and test script rewriting

Postman scripts that use the pm API, chained requests or external libraries need manual translation, and this is usually the largest one-time variable. Simple variable setting converts quickly, while complex test logic needs rewriting and retesting. Scope this as a separate line item with a script count and complexity rating from the inventory, not as a lump sum. Confirm whether the implementer reviews each rewritten script against the original responses.

Users, teams and OAuth providers

Community Edition signs users in with Email, GitHub, Google or Microsoft OAuth providers that an administrator configures, so each provider adds setup and testing work. Team workspace structure, roles and invitations also need design. Ask for the number of users, the identity providers in use and whether SAML or SCIM is required, because those requirements move the project toward the Enterprise Edition.

Hosting, PostgreSQL and SMTP setup

Hoppscotch Community Edition needs a PostgreSQL database set through DATABASE_URL and SMTP settings for email. The build step uses 4 CPU cores and 4 GB of RAM, and hosting the output uses as little as 1 CPU core and 2 GB of RAM. These are minimums from the vendor's prerequisites, so size production hosts for your user count. Recurring costs include the servers, database backups and your mail relay. Ask who owns the cloud accounts and on-call duties.

CI test migration

Teams that run Postman collections in CI need those runs moved to the Hoppscotch CLI, which is marked alpha and runs hopp test with JUnit XML output, and that needs Node.js 22 or later. Pipeline changes, reporter changes and test reruns add effort. Ask for a list of pipelines that call Newman or the Postman CLI, and confirm whether the quote covers pipeline edits or only collection moves.

Enterprise licensing and recurring fees

Community Edition is free under the MIT License, but it is installed, administered and updated by your team. If you need SAML SSO, SCIM or audit logs, Enterprise Edition requires a license key. Hoppscotch's pricing page lists Cloud Business at $6 and Enterprise at $11 per user per month, billed annually, which gives a reference point for comparison, though self-hosted Enterprise licensing is quoted separately. Confirm the license model, renewal terms and what upgrades cost before you commit.

Staff time and upgrade effort

Internal staff time covers the pilot, user training, cutover and ongoing upgrades. Community Edition releases arrive quarterly and your team applies them, so plan recurring time for testing each upgrade. Ask the implementer to separate one-time work (inventory, import, scripting, pilot, cutover) from recurring work (hosting, backups, upgrades, support retainer), and to state which items are fixed in a written scope before work begins.

Running Postman and Hoppscotch in parallel

Run the same requests in both clients for a defined overlap period so that the Hoppscotch workspace proves it returns what Postman returns before anyone depends on it. Pick a representative set of collections, including the ones with pre-request scripts, chained variables and OAuth token flows, and send each request from Postman and from the self-hosted Hoppscotch instance against the same non-production environment. Record status codes, response bodies and test results side by side. Differences usually come from environment variables that were not imported, script logic that Postman handled differently, or auth headers that were not carried over, so treat each difference as a defect in the migrated collection until it is explained.

Keep Postman read-only for reference once a collection has been verified in Hoppscotch. Stop editing shared collections, export a final copy in Collection v2.1 JSON as a record, and note in the team's runbook which workspace is authoritative for each collection. Secrets need particular care during overlap: do not paste live tokens, client secrets or API keys into the Hoppscotch environments until the self-hosted instance and its sign-in configuration have been reviewed, and keep the import files out of shared drives and Git. Confirm with your security team how long exported files may be kept. The exact retention period is the organization's decision, and it should be written down before the export is made.

Set a date after which new collections are created only in Hoppscotch, and confirm that the team's Postman subscription and seat count match what is still in use before renewal. Ask whether the Postman plan in place still requires a paid seat for read access, since this determines whether keeping Postman as a reference costs anything. The overlap ends when the CI jobs described in the CLI section no longer depend on Postman collections and the team has signed off the verified set. Note the cutover in your change record so that auditors and new engineers can see when the self-hosted copy became the source of truth.

What usually goes wrong when moving from Postman to Hoppscotch

Most failed Postman to Hoppscotch moves fail quietly rather than loudly: a script stops asserting, a sign-in loop appears, or a team keeps editing in Postman for weeks. The cards below cover the failure points that recur in self-hosted migrations and the check that catches each one before users depend on the new instance.

Silent script failures

Postman test and pre-request scripts use the pm object, and Hoppscotch uses its own pw and hopp APIs, so some assertions may not translate one for one. A request can still return a green status while a test that checks a response body or header never runs. Before cutover, run each imported request side by side in both tools and compare the test results, not only the status codes. Treat any script you cannot rewrite as a gap to confirm, not a pass.

Collections above the import limit

Self-hosted Hoppscotch accepts imports of up to 50 MB, while Hoppscotch Cloud accepts 10 MB, so a large Postman export can fail or be incomplete depending on where you import it. Collections that carry many saved example responses or large request bodies grow fastest. Measure each exported file before importing, and split oversized collections by folder into separate files. Confirm the import summary lists every folder after each batch.

Credentials copied into the new instance

Postman exports often include API keys, bearer tokens and client secrets inside environments and collection auth settings. Importing them unchanged moves those secrets into a database you now operate, and they may be readable by every workspace member. Before importing, strip live secrets from the export and re-enter them as environment variables with the correct scope. Rotate any credential that was ever shared in a Postman team workspace.

OAuth redirect misconfiguration

Self-hosted sign-in through GitHub, Google or Microsoft only works when the callback URL registered with each provider matches the public address of your instance exactly, including the scheme and port. A mismatch produces a sign-in error that looks like a provider fault. Set the public URL in the configuration first, register the callback with each identity provider, then test sign-in from a clean browser session before inviting users.

Missing SMTP for sign-in email

Hoppscotch Community Edition needs SMTP settings for email, which the email-based sign-in and invitation flows depend on. Teams that only planned for GitHub or Google sign-in often discover the gap when a colleague cannot receive a login link. Configure a working mail relay, send a test message to a real inbox, and confirm that invitations arrive and link back to your own domain.

CLI differences in CI

The Hoppscotch CLI is described as alpha, and current versions need Node.js 22 or later, so a pipeline image built for older Node or a Newman-based job will not run hopp test unchanged. Test results may also differ in reporter output and exit behavior. Pin the CLI version, run the suite against a copy of the collection in a non-production pipeline, and confirm the JUnit XML report is read correctly by your CI system before removing the Newman step.

Users who keep working in Postman

If the Postman workspace stays open and nobody sets a cutoff date, engineers keep editing collections in Postman, and the Hoppscotch copy drifts within days. Two sources of truth then produce conflicting environments and stale tests. Name a single owner for each collection, freeze edits in Postman on a set date, and confirm which collections have been moved and verified. Remove Postman team access only after the owner signs off.

Questions buyers ask before moving from Postman to Hoppscotch

How much effort and cost should we expect for a Postman to Hoppscotch move?

The cost depends mostly on the size and shape of your collections, how many environments and scripts need rewriting, and where the instance will run. Hoppscotch Community Edition itself is free and MIT-licensed, so the recurring costs are the infrastructure to host it (application containers and a PostgreSQL database), SMTP service for email sign-in, staff time to administer and upgrade it, and any implementation work you contract out. The one-time costs are the import, the script rewrite, and sign-in setup. Ask any implementation partner for a fixed-scope quote that lists the collections in scope, the scripts to translate, the identity provider to configure, and the upgrade and backup responsibilities after handover.

How long does it take to move collections from Postman to Hoppscotch?

Duration depends on the number of collections, how much of each one uses Postman scripts, and how many people need to test the result before you switch. Import itself is quick for most collections, so the time goes into checking imported requests, rewriting pre-request and test scripts, recreating environment variables, and confirming that authentication still works. Teams usually run both tools side by side for a period. Confirm the timeline with your own environment and your test owners before you agree a date, and do not plan around a number that you have not checked against your own collection inventory.

Can our internal engineers migrate the collections themselves?

Often yes for a small number of collections with simple requests, and less so when collections depend on complex Postman scripts, many environments or shared secrets. Engineers who already maintain the collections are usually the best people to verify behavior, because they know what each request should return. The work that tends to need a specialist is administering the self-hosted server: installing the containers, connecting PostgreSQL through DATABASE_URL, configuring OAuth providers and SMTP, and setting up backups and upgrades. Decide which of these your team can own over time, and document the answer before you start.

What does the migration need from our staff and our infrastructure team?

You need a named owner for the collections, people who can confirm expected responses, and an infrastructure contact for hosting. The infrastructure side includes a host or cluster that meets the Community Edition prerequisites, an external PostgreSQL database, a DNS name and TLS, outbound access to the identity providers you choose, and an SMTP relay. Check the Hoppscotch self-hosting documentation for the current requirements. Your security team should also confirm where logs, backups and collection data will sit, since the collections live on infrastructure you control.

Is Hoppscotch Community Edition enough for our team?

Community Edition covers shared team workspaces on your own server, with sign-in through Email, GitHub, Google or Microsoft OAuth providers that you configure. It is free and MIT-licensed, and its documentation says it can be used for personal and commercial projects. What it does not include is SAML-based SSO, OpenID Connect as an enterprise feature, SCIM provisioning, activity and audit logs, user groups and priority support. If your policy requires any of these, the Enterprise Edition needs a license key and is a separate decision. Confirm your identity and audit requirements against the feature list before you choose the edition.

What happens to our Postman CI test runs?

Your CI jobs need a new runner because Postman collections do not run in Hoppscotch's pipeline unchanged. The Hoppscotch CLI, installed from npm as @hoppscotch/cli, runs collection tests with hopp test from a file or from your self-hosted instance and can write JUnit XML reports. The CLI is described as alpha and current versions need Node.js 22 or later, so pin a version and test it in a non-production pipeline first. Keep the collection files in Git next to the pipeline so test changes go through review. Some teams keep Newman running for a period while they validate results, and that choice should be made explicitly.

How should we handle API keys and tokens during the move?

Do not export live secrets into shared collection files. Move them into Hoppscotch environments on your self-hosted instance, where access is controlled by your sign-in and workspace roles, and keep secret values out of exports and Git. Rotate any credential that was stored in a Postman collection or environment, because exports and old shares can persist after the migration. Confirm with your security team whether the self-hosted database backups meet your encryption and retention rules, and whether environment values need to be restricted to particular team members.

Does the 50 MB import limit matter for our collections?

It matters only if one import is large. Hoppscotch's importer accepts collection imports of up to 50 MB on self-hosted editions, compared with 10 MB on Hoppscotch Cloud, according to its importer documentation. Measure the export files you plan to import before you start. If a file is close to the limit, split the collection into smaller parts by folder or product area, and check that each part imports with its environments and scripts intact.

How DeployOpen scopes and runs a Postman to Hoppscotch migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For a Postman to Hoppscotch move, that usually means agreeing in writing who provisions the server, how the Community Edition is deployed and upgraded, which PostgreSQL instance holds the workspaces, how OAuth sign-in and SMTP are configured, and how collections are imported and checked. Most engagements are fixed-scope, so scope, deliverables and timelines are set out before any work starts. The first decision for your team is whether the migration covers one team workspace or every collection in the organization, because that choice changes the import volume, the number of environments to verify and the amount of script rewriting.

DeployOpen does not publish a price list. A quote follows from the written scope, so the useful request is a scope document that lists the Postman collections and environments in scope, the number of users and workspaces, the identity providers to be connected, the hosting target and the backup and retention rules you require. Ask the vendor to separate one-time work, such as deployment, importer runs, script rewriting and test sign-off, from recurring costs, such as infrastructure, database backups, upgrades and support. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that want the instance kept current after the cutover. DeployOpen prepares systems and evidence for compliance reviews, but it does not issue audit reports or certifications, so any assessment remains with an independent auditor.

Before signing, confirm the points that depend on your own environment rather than on a generic plan: which Hoppscotch edition your identity model needs, whether SAML or SCIM requirements push you to the Enterprise Edition, and who in your organization owns the server, the database and the secrets used for OAuth and SMTP. Read the current Hoppscotch self-hosting documentation with the implementation partner so that the chosen edition, prerequisites and upgrade path match your change calendar.