Skip to main content
Beebole can import a legacy Beebole account — people, projects, tags, rates, budgets, settings, and historical time records — into a new Beebole account. The import is run by Beebole’s support team on request, so there is nothing to install or configure yourself. It is a one-time operation per account: once an account has been migrated, it cannot be migrated again.
To request a migration, email support@beebole.com. Tell us which legacy account to import, which account it should land in, and how far back you want time records. There is no self-service migration screen in the app.

​
What gets migrated

A few details worth knowing about the conversion:
  • Rate currency. A legacy rate that carries no currency of its own — split rates and unbillable rates never do — falls back to the migrated account’s own currency, taken from the main company, rather than to a default like US dollars.
  • Clock times. An entry with a complete, same-day start and end time keeps both. Anything else — no times, only one of the two, an end at or before the start — becomes a whole-day entry. Either way the entry’s duration stays exactly what legacy reported, so report totals never move because times were imported.
  • Custom field history. A legacy field that held a history of values collapses to a single value in the new account, and the most recent one wins.
  • “No task” projects. A legacy project set to offer no activity at all keeps that behavior: its task picker offers nothing.
  • External IDs. Every legacy external ID becomes the value of a text custom field named External ID, visible on people and on the migrated project categories. Integrations that matched records on that ID read it back through the API, where custom field values are exposed like any other data.

​
Role mapping

Legacy user groups become the built-in roles of the new platform. Per-user permission settings from Legacy are not carried over, so review the role grid after the import — in particular if contractors need less access than employees, since both land in the same role.
Data can only be migrated as is. You can choose which data sets to bring over — for example people and projects but no time records — and how far back time records go, but not to restructure the account on the way in. If you want a different structure, see Review your structure before you switch.
You can ask for only active records, which skips archived people and projects. Archived records that historical time entries point at are still created, so no entry loses its project or person.

​
What to expect after the migration

The imported history is treated as closed business, so nobody has to re-submit years of timesheets:
  • Everything up to the cut-over is approved. Each person gets a single approval covering their whole imported history, so no migrated period shows up as a draft, nothing reaches an approver’s queue, and no approval email is ever sent for it.
  • The timesheet lock date is set to the last imported day. Migrated records are frozen from the start — admins included — and a period the lock date covers cannot be submitted, so imported history can’t be pushed back into the approval flow by hand.
  • Timesheet scores ignore pre-import periods. A person’s timesheet score is computed only from periods after the cut-over, so periods they never worked in the new app don’t read as missed submissions.
  • Imported entries keep the amounts legacy reported. Billing and cost figures on migrated entries come from the legacy account, so report totals reconcile with what you saw before the move.
  • Nobody is notified. Migrating people creates their records without sending invitations. Invite them from the People page in the sidebar when you are ready.
A migration is additive and can only run once per account. Because it never wipes the target account, anything you already configured there — your approval workflow in particular — survives the run untouched, and the imported data lands alongside it. Ask support for an empty account if you want a clean result.
After the migration, it is worth checking a sample of time records in Reports, reviewing the project categories and their level names, and confirming that rates and budgets landed where you expect. Master data review is the fastest way to check a whole entity at once.

​
Related content

Migration guide

How the legacy and new systems coexist, and what has changed between them.

Master data review

Check the imported configuration entity by entity, and fix it in bulk.

Account settings

Review the organization profile and account-level settings after the import.

Data exports

Export your Beebole data for backup or external analysis.

​
Frequently asked questions

Email support@beebole.com and we run the import for you. Beebole has no self-service migration screen: tell us which legacy account to import, which new account it should land in, which data sets you want, and how far back time records should go.
No. The migration is additive and runs once per account — a second run would duplicate everything, so Beebole refuses it. If something needs to be corrected afterwards, contact support and we will look at it with you.
Yes. You can leave out whole data sets — for example bring over people and projects but no time records — and set a start date so only recent entries are imported. What you cannot do is change the structure on the way in: the hierarchy, rates, and settings arrive as they were.
No. Beebole marks every imported period as approved and sets the timesheet lock date to the last imported day, so migrated history is frozen and closed. Approvers see nothing new in their queue, and per-person timesheet scores start from the periods after the migration.
No. Migrating people creates their records in Beebole without sending anything. Invite them from the People page in the sidebar whenever you are ready for them to sign in.
Administrators become Admin, employees and contractors both become Employee, team leaders become People manager, and project managers become Project manager; any unrecognized group falls back to Employee. Legacy per-user permission tweaks are not migrated, so adjust the roles — or duplicate one for contractors — once the import is done.
In a text custom field named External ID, created by the migration and visible on people and on the migrated project categories. You can read and edit it like any custom field, and scripts reach it through the API’s custom field queries and mutations.