How to export your data from CircleCI

Which CircleCI data can be exported, by method, format and limit

This table compares each category of CircleCI data by the export method, format and limit that applies to it. Read it before planning a move, because some data is already in your repositories, some must be downloaded within a fixed window and some values cannot be read back at all.

What does not leave CircleCI and the workarounds

Some CircleCI data can be copied out with the API and the repository, and some cannot. Environment variable values and expired artifacts are the two gaps that change migration planning. Each card names the gap, the workaround and what to verify before cutover.

The export sequence and how to verify each step

This sequence separates what can be copied out of CircleCI from what cannot, so that each class of data has a known destination and a check that it arrived. Run it before any cutover, while the CircleCI project and its build history are still available.

1. Inventory every repository and its CircleCI config

   The platform team lists each repository connected to CircleCI, including forks, monorepo subdirectories and archived projects, and records the path of its CircleCI configuration file. Because pipelines are defined in that file in the project repository, a clone already holds the pipeline definitions. Confirm that the configuration file exists on the default branch of every clone and on each long-lived release branch that still builds. The output is a spreadsheet with one row per repository, its config path, its default branch and the owner who will sign off the migration of that row. A repository without a config file on its default branch is a question to resolve with the owner, not an assumption to skip.

2. Export recent build artifacts through the API

   Before the retention window closes, the team lists each job's artifacts through the CircleCI API v2 endpoint for artifacts, authenticated with a Circle-Token header, and downloads each file from the URLs returned. CircleCI keeps artifacts for at most 30 days and limits single files to 3 GB, so jobs older than the window are already gone and cannot be recovered. Work from the newest builds backward, and keep a log of job numbers, file paths and checksums. The check is a count comparison: the number of files returned by the listing for each job must match the number of files on disk, and each checksum must match the value computed at download. Any mismatch is re-downloaded before the job is marked complete.

3. Export build history and test results you need to keep

   Artifacts are not the only record a team may need. The team decides which build logs, test reports and deployment references must survive the move, then saves them in a format that stays readable without CircleCI, such as plain text logs and JUnit XML files. This step is owned by the engineering lead with input from compliance, because retention obligations differ by organization. The check is a sample review: pick a few builds from each project, open the exported copy and confirm that the commit SHA, job name, timestamp and pass or fail result are all visible. Record in the migration file where the archive is stored and who can access it.

4. Record every environment variable and its origin

   CircleCI states that environment variable values cannot be read in the web app after they are set, so the platform team cannot copy them from the interface. Instead, list each variable name, the project or context it belongs to, and the system that holds its true value, such as a cloud secret manager, a vault or a password manager. Where no original source exists, mark the variable as needing rotation. Mapping the names this way shows which values can be re-entered from their source and which must be re-created. The check is a reconciliation: the count of names in the inventory must equal the count of names in the CircleCI project and context settings, and every row must name an origin or a rotation owner.

5. Rotate the secrets that cannot be recovered

   Secrets with no retrievable source should be rotated at the issuing system, such as the cloud provider, the registry or the SaaS vendor, and the new values stored in the destination CI system's secret store. CircleCI's January 4, 2023 incident report told all customers to rotate secrets after an attacker exfiltrated environment variables, tokens and keys, so the move is a natural point to rotate everything that CircleCI held, not only what was lost. Rotate in a planned order, deploy-time credentials first, and confirm each new value works in a test pipeline before the old one is revoked. The check is a test run per secret that uses the new value and succeeds, followed by a record of the revocation date for the old credential.

6. Confirm the copies in a separate location

   Store the artifact archive, config files, build history and variable inventory in a location that does not depend on CircleCI, and have a second person verify them. The verifier opens a random sample of artifacts, confirms that checksums still match, and checks that each config file in the archive matches the file on the default branch of its repository. This is the step where gaps surface, so the verifier should be someone other than the person who performed the export. The output is a signed-off migration record that lists what was exported, what was rotated, what was dropped on purpose and the reason for each exception. Keep this record with the cutover plan so auditors and future maintainers can trace each decision.

Why secret rotation belongs in every CircleCI exit plan

Export paths by team situation

Questions teams ask before exporting from CircleCI

What to plan before the CircleCI contract renews or ends

The items below set the order of work before a renewal date or contract end. Several depend on the 30-day artifact window, and most depend on facts that only CircleCI and your own contract can confirm, so check each one early.