Migrate from Smartsheet to OpenProject

Row count and sheet count set the volume of data to map, validate and reconcile, so they are the first driver of import effort. Each sheet has its own column structure, and each column must be mapped to an OpenProject work package field, custom field or type. A few large sheets with clean columns are usually cheaper to move than many small sheets that each evolved differently. Ask any quote to state the number of sheets, the approximate row count per sheet, and how many sheets are archived versus active. Ask how the provider will reconcile row counts and dates after import, and whether that check is part of the fixed scope. Internal admin time also rises with volume, because someone must confirm which rows are still live.

Smartsheet data backups exclude formulas and cross-sheet references, so every calculated column and every link between sheets must be recreated by hand or replaced with a different mechanism in OpenProject. Totals, rollups, status flags and dependencies across sheets often encode business rules that nobody has written down. Count the formulas and cross-sheet references before any quote is agreed, and ask the provider to document each one as keep, replace or retire. Work with the sheet owners to confirm the intended result, because a formula that looks obvious may carry an exception. This work is typically a one-time cost, and it grows with the number of undocumented rules.

Reports and dashboards are not in the Smartsheet backup, so each one must be rebuilt in OpenProject from its definition, filters and audience. The effort depends on how many views exist, how many people rely on them for decisions, and how complex their filters and groupings are. OpenProject provides work package tables, Gantt charts and dashboards, but the equivalence to each Smartsheet report should be confirmed in a pilot. Ask the quote to list every report and dashboard by name, state which are required at go-live, and say which are retired. Retiring unused views is often the cheapest way to shorten the schedule.

Automations and approval flows are not part of the backup, so they must be redesigned as OpenProject workflows, notifications or status transitions. Each rule that sends an alert, moves a row, or requires sign-off adds design, build and test time. Ask the provider to list every automation with its trigger, action and owner, and to mark which ones are business-critical. Approval chains that cross departments usually need stakeholder sign-off on the new design, which can extend the schedule more than the build itself. Confirm in writing which automations are replicated, which are replaced by manual steps, and which are dropped.

Single sign-on and directory synchronization are paid Enterprise features in OpenProject. Its pricing page lists SSO through SAML, OIDC, CAS, Kerberos and Okta, along with LDAP group synchronization, under Enterprise plans. If your organization requires federated login or group-based access, budget for an Enterprise plan and for the integration work against your identity provider. The effort depends on the number of identity sources, how groups map to project roles, and whether provisioning must be automated. Ask any quote to state the identity provider, the group model, and whether the Enterprise license is included or billed separately.

Hosting cost follows user count, and OpenProject publishes sizing guidance: 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Confirm whether your database platform allows those extensions, since managed services sometimes restrict them. Hosting is usually a recurring cost in your own cloud account or data center, while the setup and backup design are one-time work. Ask the quote to separate infrastructure you already pay for from new capacity, and to state backup retention and restore testing.

A parallel run keeps Smartsheet and OpenProject both in use while teams check results, so its length drives the overlap cost of two tools and the internal time spent reconciling them. The period depends on how many teams cut over together, how many reports must match, and how quickly owners can validate their plans. Smartsheet's own licensing is outside this estimate, so ask your current contract for the end date and notice terms before setting the overlap. Ask the quote to define the exit criteria for the parallel run in writing, and to state who signs off each one.

A complete cost picture has four components, each paid to a different party:

• Internal admin time for owners, reviewers and the people who validate imported data.
• An implementation partner's fixed-scope fee, which DeployOpen agrees in writing before work starts.
• Hosting in your own infrastructure, which recurs.
• OpenProject Enterprise licenses if you choose them, billed per named user per month: Basic at 5.95 euros, Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. The Community edition is free but excludes the Enterprise features discussed above.

Ask for one-time and recurring costs on separate lines, and confirm whether the Enterprise prices quoted are current on the OpenProject pricing page.

The effort depends mostly on how many sheets you have, how many of them carry formulas, cross-sheet references and reports, and how clean the data is. Cost has two parts: the OpenProject license or hosting and the labor to extract, map, rebuild and validate. The Community edition is free to download, while Enterprise on-premises plans are priced per named user per month. OpenProject's pricing page lists Basic at 5.95 euros and Professional at 10.95 euros per user per month, with a 25-user minimum for Professional. Ask any provider for a quote that separates one-time migration work from recurring support, hosting and license fees, and that lists the sheets, reports and dashboards in scope.

It depends on the inventory. A single project with a few sheets and no formulas can move in a short working session, while a portfolio with dozens of sheets, linked dashboards and automated workflows needs a longer plan. Before you commit to a timeline, count your sheets, list every report, dashboard and automation, and note which sheets depend on others. Those three counts drive most of the schedule. A written, fixed-scope plan should state the timeline and the acceptance tests for each batch.

A small, well-defined scope is often feasible in-house if you have a Linux administrator who can run Docker or packaged installs, someone who knows your Smartsheet structure, and a test environment separate from production. The team needs to export the backup, map columns to work package fields, rebuild dependencies in the Gantt view, and check dates and assignees row by row. Larger portfolios usually benefit from a second pair of hands for the mapping rules, import scripts and validation, because errors in dates and dependencies are easy to miss and costly to fix after users start working in the new system.

The work needs a few named owners and clear inputs. Assign a business owner who can decide which projects move and which are archived, a technical owner for hosting and access, and a power user per department who can confirm that migrated plans match reality. Provide read access to the Smartsheet backup, a list of sheets and their owners, and any reports or dashboards people rely on. You also need a decision on Enterprise features such as single sign-on, LDAP group synchronization and portfolio management, because they are licensed separately from the Community edition and affect the design.

No official Smartsheet importer was identified for this migration. The OpenProject Jira Migrator is in beta, supports only Jira Data Center 10.x and 11.x, does not support Jira Cloud, and its documentation advises using it only in test setups. It does not apply to Smartsheet sheets. Smartsheet data therefore moves through an export to Excel or CSV, followed by a mapping and import step built for your columns. Confirm current importer options directly with OpenProject before you plan around any tool.

Smartsheet's backup does not include reports, dashboards, formulas, workflows, cross-sheet references or formatting, so these must be rebuilt rather than restored. Formula results are exported as values, which means the logic has to be rewritten as OpenProject fields, Gantt settings, filtered work package views or dashboard widgets, or handled in a reporting tool. Make a list of every formula and report that people use, record what each one calculates, and decide which ones are still needed. Then rebuild and test them against the old outputs for a sample of projects before cutting over.

Check the export for four things: date formats, dependency references, assignee names and attachments. Smartsheet backups are a zip of Excel files with comments and attachments, so confirm that every file opens, that dates parse consistently, and that predecessor references still point to the right rows after any sorting. Map each user to an OpenProject account before import, and decide how to treat archived sheets and deleted rows. Keep the original backup read-only so every imported item can be traced back to its source row.

Yes. Run at least one full trial import into a separate OpenProject instance before the production cutover, using the same export and mapping rules. Compare the results with the source sheets for dates, durations, dependencies and owners, and record every mismatch. Keep Smartsheet active in read-only mode until the sign-off, and document how to revert if users find errors. Ask any provider to include the trial run, the acceptance checklist and the rollback steps in the written scope.