Migrate from Sonatype Nexus Repository to Pulp: what the move involves
Moving from Sonatype Nexus Repository to Pulp is a per-format migration, not a single export. Nexus stores hosted and proxy repositories by format, and Pulp runs each format as a separate content plugin with its own repository types, sync behavior and client URLs, so each Maven, npm, pip, RPM or Debian repository has to be inventoried, rebuilt and cut over on its own. Platform engineering usually owns the Pulp deployment and storage, build engineering owns the client changes in Maven, npm and pip configuration and CI pipelines, and security owns access rules, signing checks and the sign-off that nothing was dropped. Start by listing every Nexus repository with its format, type (hosted, proxy or group), blob store and the teams that pull from it, because that list sets the work.
Effort and risk are driven mostly by the mix of formats. Proxy repositories are the simpler case: Pulp rebuilds them by syncing or pulling from the upstream again, so the cost is bandwidth and time, not data movement. Hosted repositories are harder, because artifacts must be re-uploaded and their origin, versions and metadata verified, and some Nexus features such as group repositories and cleanup policies have no direct equivalent to copy across. Before committing, check the plugin maturity in the Pulp documentation for each format you run. The pulp_rpm, pulp_python, pulp_container and pulp_deb plugins are past version 1.0, but pulp_maven and pulp_npm are still 0.x releases, which means their APIs and behavior may change between versions. If Maven or npm is the core of your estate, plan a pinned plugin version, a test environment and a rollback path, and ask the implementation partner to document which upgrades you will and will not take.
Ask your team to confirm three things before the project is scoped: which Nexus features your builds depend on (such as group routing, authentication, or upload APIs), whether the Pulp plugin you need covers them, and how many repositories must cut over at once. Maven deployments with pulp_maven are a specific risk, since its deploy feature does not use authentication and does not separate SNAPSHOT from release repositories, so any publishing workflow that depends on those controls needs a compensating design. Keep the Nexus instance read-only during cutover and run both sides in parallel until each client has been verified against its new URL. Those steps should appear in the written scope so that the timeline and fees follow from what your environment actually needs.
Which Nexus capabilities map to Pulp, and which need rework
This table maps the Nexus Repository features a migration team depends on to their Pulp equivalents and marks each as clean, needs rework or gap. Read it alongside the plugin maturity notes, since 0.x plugins change more often than 1.0-plus plugins. Confirm Nexus-specific features such as cleanup policies and Community Edition limits with Sonatype before you plan the cutover.
| Nexus capability | Pulp equivalent | Status and notes |
|---|---|---|
| Hosted repositories (Maven, npm, PyPI, raw) | Pulp repositories with the matching content plugin (pulp_maven, pulp_npm, pulp_python, file) | Needs rework: artifacts must be re-uploaded or published; Nexus blob stores do not transfer directly |
| Proxy repositories to upstream | Remote objects with sync or pull-through cache, per plugin | Needs rework: content is synced from upstream again; pulp_container pull-through cache is a tech preview |
| Group repositories (virtual aggregation) | No single equivalent; use distributions and separate client URLs per format | Gap: confirm how your build tools resolve across several Pulp repositories before retiring groups |
| Maven hosted deploy | pulp_maven Maven Deploy Plugin | Needs rework: the deploy feature uses no authentication and does not separate SNAPSHOT and release repositories, so add an access layer in front |
| npm and yarn publish | pulp_npm (0.x) publish and pull-through cache | Needs rework: 0.x plugin, so pin versions and test publish flows before cutover |
| Python (PyPI) hosting and proxy | pulp_python, past version 1.0 | Clean for core hosting and syncing; confirm any Nexus-specific proxy settings with your test suite |
| RPM and Debian | pulp_rpm and pulp_deb, both past version 1.0 | Clean for mainstream use; compare repository metadata layout against your current clients |
| Container (Docker) repositories | pulp_container, past version 1.0, for sync and hosting | Clean for sync and hosting; for production image pulls and scanning, many teams pair Pulp with Harbor |
| REST API and CLI | Pulp REST API under /pulp/api/v3/ and pulp-cli | Needs rework: scripts written against Nexus REST endpoints must be rewritten for Pulp |
| Role-based access and LDAP mapping | Pulp authentication and authorization are handled outside the core; confirm the options for your identity provider | Gap or rework: map each Nexus role to an access layer decision and verify it with your security team |
| Cleanup policies and retention | Pulp orphan cleanup and repository versioning, configured per repository | Needs rework: confirm equivalent retention behavior with Sonatype's documentation and your own policy |
| Blob storage | Pulp storage backends per the storage configuration guide | Needs rework: plan a copy or re-sync of artifacts into the new backend; confirm supported backends for your estate |
What data and integrations to move, and what to rebuild
Nexus holds three kinds of state: hosted artifacts you own, proxy caches that can be refilled from upstream, and client and pipeline configuration that points at the old URLs. Each needs a different treatment, so inventory them separately before any cutover. The cards below cover what to re-upload, what to sync again, and what to reconfigure.
Hosted artifacts to re-upload
Hosted Maven releases, npm packages and Python distributions exist only in Nexus, so they must be published again into Pulp. Pulp's Maven Deploy Plugin does not use authentication and makes no distinction between SNAPSHOT and release repositories, so keep release artifacts in a separate repository that your own process controls. Export a checksum list from Nexus first, then compare checksums after upload. Confirm that each hosted repository's publish path works for your build tool before you retire the Nexus copy.
Proxy caches to sync again
Nexus proxy repositories are caches, so do not copy their contents. Point the new Pulp repositories at upstream and let them fill on demand. pulp_maven can act as a pull-through cache for Maven Central or another Maven repository, and pulp_npm offers pull-through caching for registry.npmjs.org. Pulp's container plugin syncs images from Docker Hub or any registry API, but its pull-through cache mode is a tech preview, so use sync for production images. Plan for a cold cache on day one and watch upstream rate limits during the warm-up.
Maven, npm and pip client settings
Developer machines and build agents hold mirror URLs in settings.xml, .npmrc and pip.conf. Each file needs the new Pulp repository URL, and any credentials stored in them must be re-issued. Pulp serves its content under its own path, so search your repositories for the old Nexus host name, including proxy settings and .npmrc files committed to projects. Test a clean build on a machine with no local cache, because a warm cache can hide a broken mirror entry.
CI jobs and deploy steps
Pipelines pull dependencies and push artifacts with URLs and tokens baked into job definitions, variables and deploy scripts. Pulp is driven through its REST API at /pulp/api/v3/, and pulp-cli can script repository creation, sync and publish steps, so move those steps into version-controlled pipeline code. Update each job that publishes, not only the ones that build. Keep the Nexus publish step running in parallel until every pipeline has produced a passing build against Pulp.
Authentication and access to rebuild
Nexus users, roles and LDAP or SAML mappings do not carry over automatically. Rebuild access in Pulp by defining who can read, publish and administer each repository, and issue new service credentials for CI. Pulp's authentication and authorization model should be confirmed against your version, since the pulp_rust plugin lists authentication and authorization as unsupported, a limit to check if Cargo is in scope. Map each old Nexus role to a documented Pulp permission set and test it with a least-privilege account.
Container images in the same estate
If Nexus also hosts Docker images, treat them as a separate workstream. Pulp's pulp_container plugin can sync images from Docker Hub, Quay or any registry that implements the registry API, and it syncs Cosign signatures stored as OCI images. Confirm whether your team also needs a registry for images and Helm charts, since Harbor is the documented OCI option for that content. Update image references in clusters only after the sync and signature checks pass.
Migration sequence from inventory to decommission
This sequence moves Nexus hosted and proxy repositories to Pulp one format at a time, with each step producing a record that the next step depends on. It ends with Nexus read-only and then decommissioned only after a retention period your team sets and signs off.
Inventory formats and repository types
Export the repository list from Nexus, including each repository's format, type (hosted, proxy or group), upstream URL, blob store location and the approximate number of components. Map each format to a Pulp plugin and record its maturity from the plugin's release line, so that 0.x plugins such as pulp_maven, pulp_npm and pulp_gem are flagged for extra testing. Name an owner for every repository and every consuming team. The output is a signed inventory sheet listing each repository, its target Pulp plugin, its owner and any format with no Pulp equivalent, which may need to stay on Nexus or move elsewhere.
Pilot one format end to end
Choose a low-risk format with a small, well-understood set of repositories, and stand up a Pulp instance for it in a non-production environment. Create a proxy sync from the upstream registry for a representative package set, then re-upload a sample of hosted artifacts and compare checksums against the Nexus originals. Confirm authentication and authorization behavior for the plugin, since some 0.x plugins document gaps here. The output is a tested sync log and a re-upload checksum report with zero unexplained mismatches, which becomes the acceptance criteria for later formats.
Sync proxy content from upstream again
Do not copy Nexus proxy caches. Instead, create the proxy or pull-through configuration in Pulp for each proxy repository from the inventory and let it fetch content from the upstream source again. Run the sync against the upstream directly, watch the task output for failed or skipped packages, and check that dependency resolution returns the versions your builds expect. Document any package that Pulp cannot retrieve. The output is a sync report per repository showing completed tasks, failures and the list of packages to resolve manually.
Re-upload hosted artifacts and verify
Publish hosted artifacts from the inventory into the matching Pulp repositories using the plugin's upload or deploy path, such as npm publish or a Maven deploy. Keep release and snapshot content separate where the plugin does not distinguish them, and record any repository that needs a workaround. Re-run the checksum comparison for the full set, not just the pilot sample. The output is a full re-upload checksum report, reviewed by the repository owner, with each mismatch either fixed or accepted in writing.
Run Nexus and Pulp in parallel
Point a small group of build pipelines and developer workstations at the Pulp URLs while Nexus remains the default for everyone else. Update Maven settings, npm and pip configuration files in test branches first, and track any build that fails against Pulp with its cause. Keep Nexus receiving hosted writes during this period so that rollback is possible. The output is a parallel-run log with failures classified by cause and a signed-off client change list that names every configuration file, pipeline variable and base image affected.
Cut over one format at a time
For each format in turn, freeze hosted writes in Nexus, run a final delta upload to Pulp, repeat the checksum comparison for changed content, and then move client configuration to the Pulp URLs using the signed change list. Repeat the process for the next format only after the previous one has run without unresolved client failures. The output is a cutover record per format showing the freeze time, the final checksum result, the list of clients updated and the owner's sign-off.
Set Nexus to read-only and retain
Once all formats are cut over, switch Nexus repositories to read-only so that any remaining client that still writes to Nexus is found quickly, and keep backups of the Nexus blob stores and database for the retention period your organization agrees. Monitor Nexus access logs for reads, since they show clients you have missed. The output is a read-only confirmation and an access log review that shows no active consumers before the period ends.
Decommission Nexus after the retention period
When the agreed retention period ends and the access logs show no active consumers, shut down the Nexus instance, revoke its service accounts and remove its network routes. Keep the final backup under the same access controls as other retained records. Confirm that Pulp backups and restore tests are running on their own schedule. The output is a decommission record listing removed services, revoked credentials, the retained backup location and the owner who approved the shutdown.
How the migration differs by starting point
Teams on Nexus Repository Community Edition usually run a smaller estate, but they hit the usage ceiling without warning, and that pressure shapes the whole project. The inventory is often short because fewer repositories exist, yet the team must confirm current component and request counts against the Community Edition limits before choosing a target, since those numbers determine how urgent the move is. Because Community Edition is a free tier, teams often have little documentation about who depends on which repository, so the dependency map is the first task.
- Inventory depth: List every repository, its format and every build job or developer machine that points at it, because informal consumers are common in small estates.
- Plugin risk: Map each format to its Pulp plugin and check its maturity. Formats that are still 0.x need a pilot before cutover.
- Parallel-run length: Keep Nexus read-only as a fallback for as long as the limit pressure allows, and avoid starting the parallel run late in a billing cycle.
- Proxy rebuild: Recreate upstream proxies in Pulp and sync them again, since cached content does not carry over automatically.
- Licensing decision: Compare the Pro option against the move before committing engineering time.
Confirm your current limits and the Pulp plugins for each of your formats before scheduling any cutover.
Organizations running Nexus Pro or Enterprise often use many formats across many teams, with repository policies, roles and integrations built up over years. The inventory must go deeper than a repository list: it should capture blob store locations, cleanup policies, routing rules, content selectors and the identity links that govern who can publish. Plugin risk is concentrated in the less mature formats, so each format needs its own verdict rather than a single migration plan.
- Inventory depth: Record blob stores, cleanup and retention policies, routing rules and LDAP or SSO group mappings alongside each repository.
- Plugin risk: Split formats into plugins past version 1.0 and plugins still at 0.x, and treat the 0.x group as a separate workstream with its own tests.
- Parallel-run length: Expect a longer run, because each format moves on its own schedule and build pipelines may depend on the old and new URLs at once.
- Authentication gaps: Confirm how each Pulp plugin handles authentication and authorization for publishing, since some plugins document limits here.
- Hosted content: Plan re-uploads by format, checking checksums and metadata after each batch.
Confirm the maturity and authentication behavior of every format in your inventory with the Pulp project before setting the order of work.
Some teams use Nexus almost entirely as a caching proxy for Maven Central and npm, with little hosted content of their own. This is usually the simplest starting point, because the content can be rebuilt from upstream and the Pulp plugins for these formats offer pull-through caching. The risk sits in the details: a proxy cache depends on what builds request, so the inventory should come from build logs and dependency files rather than from the repository list alone.
- Inventory depth: Take the list of upstream sources from build configuration files and build logs, not only from Nexus, since a proxy often serves more consumers than its owners expect.
- Plugin risk: Confirm pull-through behavior for your exact client versions, and note that the Maven and npm plugins are still 0.x releases.
- Parallel-run length: Keep the two proxies side by side only until a clean build succeeds from the new URL in each pipeline, which can be shorter than for hosted content.
- Hosted exceptions: Identify any internally published SNAPSHOT or npm packages, because these need separate handling and are the part most likely to need re-uploads.
- Client changes: Update Maven settings, npm registry configuration and any mirror settings in CI, and test each one.
Confirm the cache behavior and publishing limits of the Maven and npm plugins against your own builds before retiring the Nexus proxies.
What drives migration cost and duration
This table lists the cost components of moving Nexus repositories to Pulp and the drivers that move each one up or down. Use it to see where your internal time, a DeployOpen scope and recurring infrastructure each come from, then ask for a written scope and quote built on your own inventory. Nexus pricing is not stated here, so compare against your current subscription or usage figures.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Number of formats and plugins | Each format (Maven, npm, Python, RPM, Debian) needs its own plugin, client test and repository layout. Plugins still at 0.x, such as pulp_maven, pulp_npm and pulp_gem, may need workarounds or pinned versions. | Limit scope to formats in active use, retire unused repositories first, and confirm plugin gaps against the current release notes before scoping. |
| Hosted artifact volume | Re-uploading hosted artifacts takes storage transfer and verification time. Total volume also sets object storage size and backup duration. | Export a per-repository size report from Nexus, purge abandoned snapshots and release candidates, and migrate in waves. |
| Proxy resync time | Proxy content must be fetched again from upstream rather than copied from Nexus, so cache warm-up depends on upstream bandwidth and how many packages your builds touch. | Start with the lockfiles and build manifests your pipelines actually use, and schedule resync outside peak build windows. |
| Client count and URL changes | Every Maven settings file, npm and pip configuration, CI variable and build image that points at Nexus must move to the new Pulp URLs, and each team tests its own builds. | Inventory clients from Nexus access logs, publish one shared configuration template, and cut over one team or pipeline at a time. |
| Custom Nexus scripts and tasks | Groovy scripts, scheduled tasks, custom roles and LDAP mappings have no direct Pulp equivalent and must be rewritten and tested by hand. | List every script and task in the instance, classify each as retire, rewrite or keep, and ask the implementer to price rewrites separately. |
| PostgreSQL and object storage | Pulp needs a PostgreSQL database and a storage backend for artifacts. Sizing follows artifact volume and sync history, and both recur as infrastructure costs. | Confirm storage sizing from the Nexus blob store totals, and check the Pulp storage configuration guide before choosing a backend. |
| High availability and operations | Running pulpcore-api, pulpcore-content and worker processes in redundant form adds hosting, monitoring and on-call cost compared with a single Nexus node. | Decide availability targets in writing first, then size replicas to those targets rather than to peak assumptions. |
| Internal engineering time | Your platform and build teams carry inventory, testing, cutover and rollback. This is usually the largest cost in a self-managed migration and is paid in staff time, not licenses. | Assign named owners per format, freeze uploads during each cutover window, and keep a rollback path to Nexus until clients are verified. |
| DeployOpen scope and ongoing support | Implementation, hardening, backup design and documentation are priced from a written scope. Ongoing support and upgrades are optional retainers. | Ask for fixed deliverables per format, separate the migration from later support, and request a quote that lists assumptions about your inventory. |
What usually goes wrong and how to prevent it
Most failed Nexus-to-Pulp moves break at the edges: proxy content that was never fully resynced, clients that still point at the old host, and hosted repositories that were opened up during the cutover. The cards below cover the failure modes that recur in these migrations and the checks that catch each one before developers notice.
Unfinished proxy resync breaks builds
Pulp caches proxied content only after a sync or a client request reaches it, so a remote that was never fully synced can return missing or partial metadata. Builds that resolve dependencies through a half-populated remote fail in ways that look like upstream outages. Before cutover, run a full sync for every remote, confirm each task completed, and test-resolve a representative set of dependencies, including transitive ones, from a clean client cache.
pip and npm clients still on Nexus
Developer machines, CI runners, Dockerfiles and build caches often hold hardcoded index URLs for Nexus in pip.conf, .npmrc, settings.xml or pipeline variables. When Nexus is switched off, these clients fail or quietly fall back to public indexes, which bypasses your approval controls. Inventory every configuration file and pipeline variable that names the Nexus host, change them in one coordinated window, and keep Nexus read-only until the search for old URLs returns nothing.
Maven deploys without authentication
The pulp_maven Deploy Plugin does not use authentication and does not distinguish SNAPSHOT from release repositories. Exposing it on a network reachable by developers means any caller on that network could publish into a repository your builds trust. Keep deploy endpoints off public networks, place them behind your existing identity-aware gateway or reverse proxy, and treat the deploy path as an internal publishing tool until the plugin's access model meets your policy.
Lost SNAPSHOT and release semantics
Nexus enforces a distinction between SNAPSHOT and release repositories through its repository policies, and build tooling often relies on that behavior. Because pulp_maven does not separate the two on deploy, a snapshot can overwrite or be mixed with a release version without the policy you had before. Recreate the separation with separate Pulp repositories and publication rules, then test a re-deploy of an existing release version and confirm the rejection or behavior your release process expects.
Tech preview plugins in production
Some plugins are not ready for production dependencies. The pulp_rust README labels the Rust and Cargo plugin a tech preview whose APIs may change without notice, and it lists authentication, authorization and full registry syncing as unsupported. Likewise, the pulp_container pull-through cache mode is a tech preview. Check each plugin's README and the core tech-preview list before you migrate a repository, and keep any tech-preview format in a separate, documented exception with an owner and a fallback source.
Missing checksum verification after re-upload
Hosted artifacts re-uploaded from Nexus blob stores or from build servers can arrive altered, truncated or with a different checksum than the original. Consumers that pin hashes, such as lockfiles and requirements.txt hash modes, fail, or worse, accept a changed artifact if the lock was regenerated. Export SHA-256 checksums from Nexus before the move, compare them against the checksums Pulp stores after upload, and reject any mismatch before the repository is opened to clients.
What the team must own after cutover
The team owns the Pulp platform from the day traffic moves, and the first duty is version management across pulpcore and its plugins. pulpcore, pulp_maven, pulp_npm and the other content plugins ship on separate release cycles, and the 0.x plugins used for Maven and npm can change their APIs between minor versions. Treat each upgrade as a scheduled change: pin the pulpcore and plugin versions in your deployment, read the release notes for each plugin you run, and rehearse the upgrade on a copy of the database before production. The pulpcore GitHub releases page is the place to check which lines receive patches, because the project has been backporting fixes to older release lines.
Next, the team owns backup and restore of PostgreSQL and content storage together. PostgreSQL is the single source of truth for Pulp tasks and metadata, so a database restore without the matching artifact storage (or the reverse) leaves repositories pointing at content that no longer exists. Define a restore test that rebuilds a repository from backup, and record how long it took so the recovery objective is measured, not assumed. Access policy also becomes a permanent duty: decide who can create repositories, publish to hosted Maven or npm repositories and manage distributions, and review those grants on a fixed cadence. Pulp's Maven deploy path does not use authentication and does not separate SNAPSHOT from release repositories, so compensating controls at the network or proxy layer need an owner.
Finally, the team must monitor the content services as a separate concern from the API. Pulp runs pulpcore-api, pulpcore-content and pulpcore-worker processes, and a failed worker can leave sync tasks queued while the content endpoints still serve old artifacts, so watch task queues and service health for each process. Confirm with the vendor and your own environment which metrics and logs each deployment exposes. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, and a fixed-scope engagement can hand over runbooks for these duties. If your team already runs PostgreSQL, Kubernetes or Linux services at this level, it can carry this work in-house, provided the upgrade, backup and access reviews are assigned to named people before cutover.
Migrating from Nexus to Pulp: questions buyers ask
What drives the cost of moving from Nexus Repository to Pulp?
The cost depends on how many formats, repositories and clients you have, how much hosted content must be re-uploaded, and how much you run yourself. Plan for four cost components: the Pulp infrastructure (compute, PostgreSQL, Redis, object storage), the internal team time for inventory and client changes, any implementation support you buy, and ongoing operations. The infrastructure is recurring; the migration work is one-time. Nexus costs are different: Pro or Enterprise subscriptions are priced by server count, components and requests, or by consumption for Nexus Repository Cloud, so ask Sonatype which metric applies to your estate. Pulp itself is GPLv2+ licensed, so there is no per-seat license to renew. Ask any implementer for a quote built from a written scope that lists formats, repository counts and client types.
How long does a Nexus to Pulp migration take?
No timeline can be stated from the supplied facts, so treat any duration as something to agree in writing. The main variables are the number of formats, the volume of hosted artifacts that must be re-uploaded, how many proxy repositories must sync again from upstream, and how many build pipelines and developer machines need new URLs. Maven, npm and pip clients are usually changed in configuration files and CI variables, which is quick per project but slow across many teams. Plugins at 0.x maturity may need more testing time. Ask for a phased plan that moves one format at a time and includes a rollback window for each.
Can our internal team run this migration without outside help?
Yes, if you have people comfortable with Linux, PostgreSQL, object storage and the build tools that read from your repositories. The Pulp command-line client and REST API at /pulp/api/v3/ make inventory and scripted uploads practical, and the official container images help with a Docker Compose or Kubernetes deployment. The harder parts are usually inventory of undocumented proxy rules, credential mapping, and testing every pipeline that depends on Nexus. If your team has none of these skills in-house, or a regulated change window is tight, an implementation partner can take a fixed-scope piece such as the inventory, the deployment or the client cutover. DeployOpen plans, implements and documents these self-hosted platforms in your environment under a written scope.
Which formats are safest to move to Pulp first?
Start with the formats whose Pulp plugins are past version 1.0, because their release history is longer. According to their GitHub releases in October 2026, pulp_rpm (3.39.2), pulp_python (3.37.1), pulp_container (2.30.0) and pulp_deb (3.11.1) are in that group. Maven (pulp_maven 0.35.0), npm (pulp_npm 0.10.2) and Gem (0.8.0) are still 0.x, so test them against your real clients before cutover. Treat Rust and Cargo as a later move: the pulp_rust README labels it a tech preview whose APIs may change, and it lists authentication, authorization and full registry syncing as not yet supported. Confirm current versions with the pulp project before you plan, since releases move quickly.
Does Pulp handle Maven deploys and authentication the same way as Nexus?
Not exactly, and you should check this before you commit. pulp_maven can act as a pull-through cache for Maven Central or another Maven repository, which covers most proxy needs. Its Maven Deploy Plugin support, however, does not use authentication and makes no distinction between SNAPSHOT and release repositories. Teams that publish internal libraries through Nexus rely on those controls, so either place an authenticating proxy in front of Pulp, or confirm the current plugin behavior with the Pulp maintainers and test it. Record the gap in your risk register with an owner and a decision date.
How do we re-sync proxy repositories and re-upload hosted artifacts?
Proxy repositories are not copied; Pulp pulls them again from upstream. Create a remote for each upstream source (Maven Central, registry.npmjs.org, PyPI or your container registries), sync, and confirm package counts against Nexus. Hosted repositories must be exported from Nexus and uploaded to Pulp with the matching client, keeping checksums so you can verify each file. Keep Nexus read-only during the final sync to avoid drift. Ask your implementer to produce a checksum comparison report as evidence that the transfer is complete.
How should we request a quote for this migration?
Ask for a quote built from a written scope rather than a headline figure. Your request should list the Nexus edition and subscription type, every format and repository type in use, the approximate number of hosted artifacts and proxy remotes, the clients (Maven, npm, pip, CI runners) that must change, the target hosting (Kubernetes, Compose or virtual machines), and your compliance evidence needs. Ask for deliverables, acceptance criteria, rollback steps, handover documentation and any ongoing support as a separate line. DeployOpen does not publish a price list; a quote follows from the scope agreed in writing before work starts. You can also ask the Pulp project what it expects for hosting and maintenance.
Licensing and what Pulp does not cover
Pulp is free to run, so the change is in labor, infrastructure and support, not license fees. Pulp core and its content plugins are licensed under GPLv2 or later, and the project describes itself as completely free and open source. Moving off Nexus removes the subscription or consumption charges, but it adds costs you will carry yourself: servers or Kubernetes capacity, PostgreSQL, object storage, backups, upgrades, and the engineering time to run them. Ask any partner for a quote that separates these components and shows which recur each year. Before you rely on GPL-licensed code in internal tooling or in any distributed product, confirm your obligations with counsel, especially if you modify Pulp or redistribute it.
Not every format Pulp covers is mature, and two features are tech previews. Several plugins are past version 1.0 (pulp_rpm, pulp_python, pulp_container and pulp_deb), while pulp_maven, pulp_npm and pulp_gem remain 0.x releases whose interfaces may still change. The pulp_rust README labels the Rust and Cargo plugin a tech preview whose APIs may change without notice, and it lists authentication, authorization and full registry syncing as not yet supported. Pulp's pull-through container cache is also a tech preview. If your Nexus estate depends on Cargo or on pull-through caching of container images, plan either a different component for that content or a formal risk acceptance before cutover. Check each plugin's release notes against the versions you intend to deploy, and test the exact workflows your build pipelines use.
How DeployOpen scopes and runs the migration
A Nexus to Pulp move touches inventory, sync, client configuration and operations at once. DeployOpen agrees the scope in writing first, then builds, hardens, documents and supports the Pulp platform inside your own infrastructure so each phase has a defined owner and exit check.
Fixed-scope agreement first
Scope, deliverables and timelines are agreed in writing before work starts. For this migration, the written scope should list every Nexus repository by format and type, which Pulp content plugins are in use, which hosted artifacts must be re-uploaded, and which client configurations change. Ask for the acceptance criteria per deliverable so a finished migration can be checked against the list.
Format and plugin assessment
Before any build, the plugin choice is tested against your actual formats. Plugins such as pulp_rpm and pulp_python are past 1.0, while pulp_maven and pulp_npm are still 0.x releases. The assessment records which 0.x plugin features your teams depend on, such as Maven deploy without authentication, and what compensating controls or fallbacks apply.
Platform build inside your infrastructure
DeployOpen implements the Pulp deployment in your cloud accounts, data centers or air-gapped networks, using the services and storage backend your standards require. Confirm during scoping how PostgreSQL, object storage, Redis and ingress are provisioned, and which of Pulp's official container images your operators will run.
Hardening and access controls
The Pulp instance is hardened to your baseline, covering TLS on the API and content endpoints, service account separation, secrets handling and logging of administrative actions. Because Pulp's user and role model must replace Nexus roles and LDAP mappings, DeployOpen documents each mapping so access reviews can trace who can sync, publish or delete content.
Backup and recovery testing
Backups cover the PostgreSQL database, which Pulp treats as the single source of truth for tasks, and the artifact storage. A restore is rehearsed in a separate environment before cutover, and the results are recorded. Confirm with the team the recovery point and recovery time targets they need, since these drive storage and replication design.
Documentation and ongoing retainers
Runbooks cover sync schedules, client URL changes for Maven, npm and pip, upgrade steps and rollback. Ongoing support, upgrades and continuous testing are available as retainers, which fit plugin releases that arrive frequently across the Pulp ecosystem. Ask for the retainer's response expectations in writing before signing.
