How to export your data from Basecamp

How to export data from Basecamp before access ends

A renewal notice, a price change, a data residency requirement or a decision to exit Basecamp usually means the team needs its project content somewhere else, and the window to get it out is shorter than it looks. The documented routes are the owner-only HTML export, which covers all, selected or archived projects, the separate Ping export, and the OAuth 2.0 API for structured data. Cancelling removes access to the account, so every export has to run while the account is still active and while someone with the owner role can sign in. Treat the export as a small project in its own right, with a named owner, an agreed date set by leadership and a written record of what was exported and when.

Start with the HTML export, since it carries most of the projects, to-dos, message boards and files that a migration depends on. Because the export is limited to owners, confirm early who holds that role and whether a second owner can run the export if the current one leaves. Choose between all projects, selected projects or archived projects based on what the target system needs, and do not assume archived projects appear in a full export until you have checked. Ping is a separate export with its own controls and should be treated as sensitive. Before anyone downloads it, agree with legal or HR whether it belongs in the migration at all and who may receive the files.

The OAuth 2.0 API is the route for structured data, meaning records you can map into fields and relationships in OpenProject or Nextcloud. It requires a developer to register an app, obtain authorization from a user and write the extraction code, so budget that work as its own task with its own cost. Whichever route you choose, confirm Basecamp's export limits, the file formats it produces and what each export leaves out in Basecamp's current help documentation, because these details change and should not be taken from memory. Then run a test export of one representative project, open the files, check that comments and attachments came through, and record the results. Schedule the final export and the cancellation date only after that test has passed.

What Basecamp exports, by method and format

This table compares the three Basecamp export routes by data type, method, format and limits. Read the limits column as a checklist: where a limit is not confirmed in the sources behind this page, check it with Basecamp support or in your own account before you plan the migration. The main takeaway is that the HTML export covers project content, the Ping export is handled separately, and the API is the route for structured records that a migration script can read.

Data type	Export method	Format	Limits to confirm
All projects	Owner-only HTML export of every project	HTML export archive	Confirm file size caps, attachment handling and how long download links stay valid
Selected projects	Owner-only HTML export of chosen projects	HTML export archive	Confirm whether selection is per project and whether comments and files are included
Archived projects	Owner-only HTML export of archived projects	HTML export archive	Confirm whether archived projects are listed in the export and how they are packaged
Ping data	Separate Ping export, outside the project export	Confirm format in your account	Treat as sensitive personal data; confirm scope and who may request it
Structured data (to-dos, messages, files)	OAuth 2.0 API, called by an authorized app	Confirm response format in the API reference	Confirm rate limits, pagination and how attachments are downloaded
Who may request an export	Account owner for the HTML export	Not applicable	Confirm whether admins or members can request any export type
Attachments and files	Included in HTML export, fetched separately through the API	Confirm file names and folder layout	Confirm whether every attachment version is included and whether any are skipped

What the export leaves out and how to cover the gaps

The Basecamp export covers project content, but several kinds of work sit outside it: material only other people can reach, integrations, Ping conversations, settings and attachment details. Each gap needs a check and a manual or API capture step completed while owner access is still active.

Content only non-owners can reach

Some material in a Basecamp account may be visible only to certain people, such as private to-dos, messages or files shared with individuals who never placed them in a project the owner administers. Before you run any export, list every project you can see and ask each project's people which content they hold outside it. Confirm the scope of the owner export in Basecamp's export help. For anything you cannot reach, ask the person who holds it to export or copy it into a document you control before the account closes.

Integrations and automations

Third-party apps, webhooks and automations connected to Basecamp run outside project content, so the HTML export carries none of their configuration. A connector that pushes new to-dos into another tool will stop when access ends, and the destination may keep stale data. Review every connected app and webhook in account settings, then record the target system, trigger and field mapping in a document. Rebuild each one in the replacement platform's own automation tooling and test it with a sample record.

Ping conversations need separate handling

Ping, Basecamp's messaging feature, has its own export with a more sensitive data set than project exports. Treat it as a separate migration stream and confirm in Basecamp's documentation who can request it and how it is delivered. Classify the output before anyone opens it, limit access to the people who need it, and store it under a retention period you set in your own storage. Decide whether any conversations move into a chat tool at all, and log the export date and recipients for later audit.

Settings and permissions

The HTML export records what was written in projects, but it does not describe how the workspace was configured. Project access levels, invited people, notification preferences and any templates or recurring schedules depend on settings held outside the content. Before cancellation, list each project's people and their access level in a spreadsheet, note template and schedule names, and capture account settings with screenshots. Compare this list against the export contents to see exactly what you still need to record.

Relationships only the API preserves

The HTML export is designed for reading, so links between records such as a to-do's assignee, its list, its comments and its completion history can be hard to rebuild from flat files. The OAuth 2.0 API returns structured data that keeps record IDs and relationships intact. Plan a small extraction script that uses an authorized token to pull projects, to-dos, messages and comments, and store the JSON alongside the export. Check Basecamp's developer documentation for current endpoints and rate limits, and test on one project first.

Attachments and file versions

Files attached to messages, to-dos and documents may appear as references to the original files, so the archive may not hold every copy you expect. Compare the number of files in each project against what Basecamp displays, and download anything missing while owner access is still active. Keep original file names and folder structure, and note which version each replacement file represents. Confirm in Basecamp's help center how attachments are packaged so you know what the archive contains before you rely on it.

Why export before cancellation removes access

Export your Basecamp data before you cancel, because once the subscription ends, the owner export and API access that depend on an active account stop. Any project, to-do, message board or file that nobody has copied can then be lost to your team. Treat cancellation as the point where the copy must already exist, not as the moment you start looking for one. Read Basecamp's terms and confirm whether any content remains accessible after a plan lapses, how long that window lasts, and whether an owner can still request an export during it. Do not plan around a grace period you have not confirmed in writing.

The owner role is the practical risk. The export is an owner-level action, so if the person who holds ownership has left the company, the export may stall until someone else can act. Confirm now who will hold ownership at the end date, and confirm that person can see every project that must be copied, including archived ones. Run a test export of one project well before the planned cancellation so you learn about permission gaps while the account is still active. Staff turnover during a migration is common, so record the owner and the export date in your project plan.

Keep the export as a dated record of what existed at exit. Store it in a location your organization controls, label it with the account name and export date, and note who ran it and which projects it covered. That record answers later questions from auditors, customers or former staff about what was held and when. It also becomes the source file for moving work into self-hosted OpenProject or Nextcloud. Before you rely on the copy, open a sample of files and check that to-dos and message board posts are readable, because a copy you cannot read gives you no record at all.

Sequence for a complete export and verification

This sequence produces a dated, access-controlled archive of Basecamp projects, files, messages and personal messaging data, checked against the live account before cancellation removes access. Each step closes with a record that the next step depends on.

Confirm the owner account and its holder
Confirm which Basecamp account holds owner rights, since the HTML export is limited to owners. Name the person who holds the login, their backup contact and the device or password manager where credentials are kept. Check that the owner can still sign in and that multi-factor authentication recovery is in place. Record the account name, owner names and the date of the check in a short export log. The step is done when a second trusted person has reviewed that log and agreed who will run each export.
Inventory active, archived and selected projects
List every project in the account and mark it as active, archived or selected for export. For each project, note its name, owner, last activity date, approximate number of to-dos, message board posts and files, and any items that other teams still reference. Archived projects are easy to miss, so search for them separately. The output is a register that becomes the checklist for every later step. Confirm the register with the business owner of each project before exports begin, so no project is left out by accident.
Run the HTML export for each project set
Using the owner account, run Basecamp's HTML export for the full account, for selected projects and for archived projects, following the options shown in the account's export settings. Save each output file with its set name and export date, and keep the original download untouched. Open the index and a sample of project pages in a browser to confirm the content is readable offline. Tick each project off the register once its pages open correctly. The step is complete when every project in the register appears in at least one export file.
Run the Ping export under restricted access
Treat the Ping export as a separate, sensitive dataset because it contains direct messages and personal communications that the HTML export does not cover. Limit the people who can run and receive it to named individuals approved by the owner, and record each person's role. Store the file in a restricted location, log each access, and check whether your privacy, employment and records policies allow retention before you keep it. The step is complete when the approver has signed the handling record and the Ping file is stored in the restricted location.
Pull structured records through the OAuth 2.0 API
Where you need structured data such as to-do lists, comments or project metadata in a machine-readable form, use Basecamp's OAuth 2.0 API. Register an integration, authorize it with an account that has the right access, and script read-only requests that page through each project. Save the responses as JSON with timestamps and the request parameters used. Keep the API client secrets in a secrets manager, not in scripts. The step is complete when record counts from the API match the register for each project you selected.
Store the archive in an access-controlled location
Copy the HTML exports, Ping export and API output to storage on your own servers, separated into folders by project set and export date. Apply named-group access controls, enable audit logging and encrypt the storage volume. Keep at least one additional copy in a separate location you control, and write a README that states the source account, the export date and the person responsible. The step is complete when a test user outside the approved group cannot open the folders and the audit log records the test.
Verify counts, dates, attachments and comments
Compare the archive with the live Basecamp source before cancellation. For each project in the register, check the number of to-do lists, to-dos, message posts, comments, files and attachments, and confirm that sample creation and update dates match. Open a set of attachments and confirm they download and open. Record any gap, rerun the affected export, and check again. Keep a verification sheet showing the live count, the archive count and the reviewer's initials for each project. The step is complete when every project shows matching counts and no open gaps.
Sign off and date the archive
Obtain written sign-off from the account owner, the data owner for each project and the person responsible for records or compliance. Attach the register, export log, Ping handling record, API output notes and verification sheet to the sign-off. Date the archive, seal the final copy as read-only and record its location in your asset inventory. Only after this sign-off should the team cancel the Basecamp subscription or remove users. The step is complete when the signed record is filed and the archive is listed as the authoritative copy.

Which export path fits which team

For a small team with a handful of active projects, the HTML export is usually the core of the work. It packages to-dos, message boards, docs, files and schedules in a browsable format that a non-developer can open and read. Because the export is run by the account owner, this is the step that most often falls to one person, so plan for that person to be available before any cancellation date.

Choose the scope deliberately: Decide whether you need all projects, selected projects or archived projects. Archived projects are easy to overlook and are often the ones that hold the decisions people later need to find.
Open a sample of files: Check that attachments, comments and documents appear and open correctly. A successful export job does not confirm that every file is readable.
Compare against the live projects: Spot-check to-dos, completion dates and message threads against what you see in Basecamp.
Store a copy you control: Keep the export on storage your organization manages, with a named owner and a retention period.
Plan the destination: Decide whether OpenProject or Nextcloud will hold these records, since that determines how you reorganize the files afterward.

Ask the account owner to confirm which projects the export covers, where the download is delivered and how long it remains available. Verify that the export completes before access is removed.

What the target platform needs before the archive arrives

Basecamp's export produces files, not a working project system, so the destination has to be ready before the archive arrives. The cards below cover hosting, database, upgrade discipline and backups for OpenProject or Nextcloud. None of the supplied sources documents a Basecamp importer for either platform, so confirm import support before you choose a route.

Size the hosting first

OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, with 8 cores and 8 GB for about 500 users and 16 cores and 16 GB for about 1,500 users. Size against your peak concurrent users, not your headcount, and reserve capacity for the import run itself. Ask whether your Basecamp export size will add load during the migration window.

Provision PostgreSQL 16 or later

OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Confirm these extensions are available on your managed or self-managed database before installation, since a missing extension will block setup. Plan the database backup schedule alongside the file backup so attachments and records stay consistent.

Match Nextcloud 35 dependencies

Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, PHP 8.5 and Apache 2.4 or nginx with php-fpm. Check the supported ranges in the system requirements before you pin versions, because Oracle Database is only available with an enterprise subscription. Confirm which web server and PHP build your platform team already patches.

Back up before every upgrade

Nextcloud does not allow skipping major releases, so you must move one major version at a time, back up before each step, and disable third-party apps until they are confirmed compatible. Plan for these upgrade steps from day one, because the imported Basecamp content will sit on whichever version you installed. Record the upgrade path in your runbook.

Choose a tested backup method

Nextcloud All-in-One is the official installation method and includes BorgBackup-based backups, so it is a practical starting point for a Nextcloud target. Whatever tool you choose, test a full restore of files and database to a separate host before the migration. Confirm the retention period and where backup repositories are stored.

Confirm the import route

The supplied sources document importers for Jira, Linear, Asana, ClickUp and others on Plane, but none for Basecamp into OpenProject or Nextcloud. Ask the vendor or your implementation partner whether a Basecamp importer exists, or whether the route is a scripted transform of the export. Settle this before you build the target, because it decides how much mapping work your team must budget for.

What does a Basecamp data export cost and take to do

How long does a full Basecamp data export take?

No single duration fits every account, and the effort depends mostly on how much data sits in it. The main drivers are the number of projects, whether they are active or archived, the volume of attachments in to-dos, message boards and files, and whether the business needs structured data in addition to readable HTML. A small account with a few active projects can often finish the HTML export and check it in a short working session. An account with years of files and many archived projects takes longer to inventory, export and verify. Before starting, list every project, mark which ones must be kept, and total the attachment storage. Then confirm the current export options in your Basecamp account, since those tools can change.

Can our own team export Basecamp data without outside help?

Yes, for the HTML export. An account owner can run Basecamp's HTML export for all projects, selected projects or archived projects without outside help, which suits teams that need readable copies for records or for a move. The Ping export is separate and needs a deliberate decision because it can contain sensitive direct messages. Structured data is different. Pulling it through the OAuth 2.0 API requires someone who can register an application, handle tokens, page through requests and map JSON into the target schema, so that work needs developers. Many teams use an owner for the HTML export and bring in developers only if the target system needs structured records.

What does the business need to provide before a Basecamp export starts?

The business needs to provide four things: owner-level access to the Basecamp account, a decision on whether Ping content is exported and where it goes, a named person who verifies the export, and an agreed cutoff date. Owner access matters because only owners can run the HTML export. The Ping decision should involve the people accountable for privacy and records, since those conversations may hold personal or confidential material. The verifier should compare project counts, file presence, comments and dates against the live account. Set the cancellation date only after verification, because cancellation removes access to the content. Record who approved each decision in writing.

Do we need a consultant for a Basecamp data export, and what should the scope cover?

A consultant is optional. Teams with simple accounts and capable administrators often handle the HTML export themselves. Outside help becomes useful when there are many projects, large attachment volumes, structured data needs, or a target such as OpenProject or Nextcloud that must be configured and checked. DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A written scope should list the projects in and out, the export methods, the target setup, the verification steps, the handover documents and the exclusions, including how Ping content is handled.

How long should we keep a Basecamp export, and where should it be stored?

Keep the export for as long as your retention policy, legal hold rules and contracts require, and confirm that period with your legal or compliance owner before deleting anything. No fixed retention period applies across organizations. Store the archive in a location you control, such as an encrypted volume or object store inside your own infrastructure, with access limited to named roles and logged. Keep a checksum or manifest for the archive so later copies can be compared with the original. If you keep the Ping export, place it in a separate, more restricted location. Include the storage in your backup plan and review access on a schedule. DeployOpen can prepare documentation and controls for this, but independent auditors decide whether they meet a given requirement.

What does a quote for a Basecamp export depend on?

A quote depends on the written scope, so the inputs matter more than any general figure. The main inputs are the number of projects and their state, the total attachment volume, whether Ping content is in scope, whether structured data through the API is required, the target platform and its configuration, the verification method, retention and storage arrangements, and documentation and handover needs. DeployOpen does not publish a price list, and a quote follows from the agreed scope. Ask any provider for an itemized quote that separates export work, target setup, data mapping, verification, documentation and any ongoing support retainer. Ask which items are one-time, which recur, and what the quote excludes.

What to plan before renewal or termination

Basecamp exports only run while your account can still produce them, so the export is a deadline problem as much as a technical one. The cards below cover the decisions to make early: timing, ownership, retention, target licensing and a test import.

Set the export start date

Work backward from the renewal or cancellation date and begin the export well before it. Basecamp access ends with the account, so a late export can leave gaps in attachments, Ping conversations or project history that cannot be recovered later. Schedule the export as a named task with an owner, and record when each project export finished so you can match the archive against what the team expects to find.

Confirm ownership and role transfer

Only the account owner can run the full HTML export, so identify who holds that role before the export begins. Check whether the owner role can be transferred to another administrator and whether that person has the access needed to export every project. If the owner has left the company, resolve this with Basecamp first, because the export path depends on it.

Agree retention and legal hold rules

Decide with legal and compliance how long exported Basecamp content must be kept, and whether any projects are under legal hold. Exports often include personal data, so the archive needs the same access controls and deletion rules as your other records. Confirm current retention terms, data handling and deletion commitments with Basecamp before you rely on them.

Plan the target licensing

Choose the target platform and its license model before the export, because licensing shapes what you pay after cutover. OpenProject Enterprise on-premises is priced per named user per month, with Professional requiring a 25-user minimum, according to the OpenProject pricing page. Compare that with the Community edition, Nextcloud Enterprise minimums and your own hosting and administration costs, and ask each vendor for a written quote tied to your user count.

Run a pilot import

Import one or two representative projects into a test instance before the contract ends. Use the pilot to check that to-dos, message boards, comments, files and due dates map to the right objects and that attachments open correctly. Record every gap, then decide whether to rebuild those items by hand or request a fix, while there is still time to use the Basecamp export as a fallback.

How DeployOpen scopes a Basecamp data exit

DeployOpen treats a Basecamp export as a scoped engagement, starting with an inventory of what the account holds and what must survive the move. The work is planned, built and checked inside your own infrastructure, so exported content and any migration tooling stay under your control.

How we scope

Inventory every project, to-do list, message board, schedule and file set your owner account can export.
Decide which content is exported as HTML, which is pulled through the API, and which is handled separately.
Agree the export window before cancellation, so access is not lost while content is still unverified.

How we build

Run the owner-only HTML export and confirm archives open and contain the expected projects and attachments.
Map exported items to target fields in a self-hosted OpenProject or Nextcloud instance on your servers.
Test the import in a non-production environment and record which items need manual rework.

How we hand over

Deliver a written record of what was exported, what was imported, and what was excluded or left behind.
Document the export steps, file locations, checksums and retention decisions so your team can repeat them.
Handle the Ping export and any personal data as a restricted item, with access limited to named staff.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Support covers the self-hosted target after cutover, including backups taken before each upgrade.
Ask for a quote built from the written scope, since DeployOpen does not publish a price list.