Open-source alternative to SharePoint lists

Open-source alternative to SharePoint lists: the short answer

A team that runs issue, asset or request trackers in SharePoint lists and wants them off the commercial platform or inside its own servers has two main self-hosted options: Baserow and Grist. Both are spreadsheet-style databases with views, record-level editing and REST APIs, and both run in containers on infrastructure you control. For most teams the move is less about copying data and more about rebuilding the parts around it: forms, per-view and per-table permissions, notifications and the automations that used to run on list events. Plan that rebuild as a separate workstream with its own owner and test cases, because it is where most of the effort sits. The gaps matter as much as the overlap. SharePoint lists do not map one to one onto either product, so column types such as managed metadata, person fields with group expansion and calculated columns need a deliberate mapping to Baserow or Grist field types, formulas and lookups. Workflows built in Power Automate or SharePoint designer logic will not transfer as they are and need a replacement engine. Some enterprise controls sit behind paid tiers: Baserow lists single sign-on and role-based permissions and audit logs on its Advanced plan and above, and Grist requires an activation key to connect directly to an identity provider over OIDC or SAML. Confirm your required SSO, audit and retention controls against the current license terms before you choose.

Start with an inventory: list every SharePoint list in scope, the columns each one uses, which views and forms people rely on, and which flows read or write it. Export each list to CSV, check that the exported values survive a round trip into a test instance, and record which columns need manual rework. Then decide per list whether it belongs in Baserow, Grist or stays in SharePoint for now. Grist is built on SQLite and supports Python formulas, which suits teams with analyst skills. Baserow is headless and API first, which suits teams that want a database behind a custom application. Either way, ask your implementation partner for a written scope that covers the rebuild, access model and testing, since the cost of the platform itself is usually smaller than the cost of re-creating the list logic.

Which SharePoint list capabilities map to Baserow and Grist

This table maps the main SharePoint list features to Baserow and Grist, marking where each option is complete, partial, gated behind a paid license or handled differently. Use it as a checklist for a proof of concept, and confirm field and permission behavior on a test instance before you commit list data or automations to either tool.

Capability	Baserow	Grist	Notes for the migration
Columns and field types	Spreadsheet-style fields including links, attachments and relationships, with formula, lookup and rollup fields available in the table editor	Typed columns with Reference fields and formulas written in Python with many Excel functions	Map SharePoint choice, lookup and person columns to the closest field type, then check each one in a test base. Neither tool copies SharePoint column types automatically.
Views and filtering	Grid views with filters and sorts; additional view types depend on the Baserow version you deploy	Multiple views per page with sorting, filtering and grouping on the same table	Rebuild the views that SharePoint list views and filters depended on. Test the views users rely on most.
Forms for data entry	Forms are available for collecting records, with field-level settings to confirm on your version	Forms can be built on a table, with entries written directly into the document	Test required fields, validation and attachments in each form before users rely on them for intake.
Item-level permissions	Role-based permissions and audit logs are listed for the Advanced plan, so confirm the granularity you need on your license	Access rules control who can see or edit tables, columns and rows, with the level of detail set in the document	SharePoint unique permissions on individual items are a common gap. Check whether each tool meets the row-level rule you need.
List-level and workspace permissions	Workspace and database roles, with role-based permissions on the Advanced plan	Document-level sharing and access rules, with user roles managed in the Admin Panel	Map SharePoint site groups to workspace or document roles before import so permissions are not rebuilt by hand.
Sign-in and user management	Single sign-on via SAML, OAuth 2.0 providers and generic OpenID Connect requires the Advanced or Enterprise plan with an activated license	Forwarded-header authentication and Sign in with getgrist.com are included, but OIDC or SAML needs an activation key; SCIM is supported	Plan identity integration before go-live, since the paid license affects how users sign in.
REST API access	Headless and API first, with API access documented for building against the data	REST API with an interactive API console	Replace SharePoint REST calls and Power Automate triggers with the tool's API. Test authentication and rate behavior in a test instance.
Versioning and attachments	Attachments are supported and copied from Airtable imports, but no revision history is included in the import path	Document history is available for rollback on supported editions, and attachments are stored with the document	SharePoint version history on list items does not transfer. Archive the old export if audit trails matter.
Import and export	CSV, Excel, XML and JSON import, plus export of table data	Import and export to Excel and CSV, with data stored in SQLite that other tools can read	Export each list to CSV before migration and check dates, multi-value fields and attachments in the output.
Workflows, alerts and automations	Automations and dashboards are included in the product, with plan limits to confirm	Automations are not in grist-core, so they need a paid full edition to run	Power Automate flows and SharePoint alerts must be rebuilt. Count the flows that depend on each list before choosing a tool.

When Baserow or Grist fits better for list replacement

Baserow and Grist both replace SharePoint lists with self-hosted, spreadsheet-style databases, but they fit different work. The cards below cover licensing, data model, deployment and the features that sit behind paid plans or activation keys, so you can match the tool to the list you are replacing.

Baserow for application-style databases

Baserow is a spreadsheet database hybrid that also builds applications, portals, automations and dashboards. Its core is MIT-licensed, but premium and enterprise features sit outside that grant. Choose it when lists become front ends for several teams, such as an intake portal feeding a request tracker. Check which features your team needs before you commit, because single sign-on and some permission controls are on the Advanced and Enterprise plans with an activated license.

Baserow deployment and data layer

Baserow runs on Django, Vue.js and PostgreSQL and is headless and API first. The baserow/baserow Docker image bundles an internal PostgreSQL and Redis by default, but Baserow highly recommends an external PostgreSQL for production. Docker Compose with separate backend and web-frontend images, or Helm on Kubernetes, suits horizontally scaled deployments. Ask your platform team who operates the database, backups and upgrades, since those duties stay with you.

Grist for formula-heavy trackers

Grist is released under the Apache License 2.0 through grist-core and stores documents in SQLite. Its formulas support full Python syntax, including the standard library, and many Excel functions. Pick Grist when a SharePoint list carries calculated fields, scoring or custom logic that analysts maintain. Because formulas are code, review them as you would any script and agree who may change them.

Grist API and portable data

Grist offers a REST API with an interactive API console, import and export to Excel and CSV, and optional gVisor sandboxing per document on Linux or with Docker. Because documents are SQLite files, other tools can read the numeric and text data directly. This portability reduces lock-in, but you still need to rebuild any SharePoint Power Automate flows that read the list. Test the export and the API calls against a copy before cutover.

Paid features on both platforms

Baserow's SSO and advanced permissions require paid Advanced or Enterprise licensing for self-hosted use. For Grist, OIDC and SAML single sign-on, audit log streaming, Advanced Admin Controls and automations are outside grist-core, and direct identity provider connections need an activation key. Forwarded-header authentication and SCIM user management are available across editions. Put these licensing questions in writing before you design access, because they determine how your identity provider connects.

Fit check before choosing

Use Baserow when the list is a shared application with views, forms and portal access for many users. Use Grist when the list is a calculation-heavy tracker maintained by a small group who write Python or Excel logic. Many organizations will find that a single list does not fit either pattern cleanly, so pilot both on one real list. Record the audit, permission and automation requirements first, then compare them against each license tier.

How the list platform fits next to SharePoint Online or Microsoft 365

This situation fits teams whose document libraries, version history and Microsoft 365 licensing stay in place, while only list-based trackers and small databases move to Baserow or Grist. The list platform runs beside SharePoint as a separate application, so the two systems need a clear boundary: which records live in the list tool and which documents remain in SharePoint.

Identity: Users sign in to the list platform through SSO against the same identity provider that backs Microsoft 365, where your plan and the product tier allow it. Baserow SSO for SAML and OpenID Connect requires an activated Advanced or Enterprise license, and Grist needs an activation key for direct OIDC or SAML.
Attachments: Files attached to rows or records are stored by the list platform on your servers, not in SharePoint, so they fall outside SharePoint retention and eDiscovery.
Links: A row can hold a URL pointing to a SharePoint file, which keeps working only while the user has access to that file in Microsoft 365.
Licenses: Microsoft 365 licenses for SharePoint, OneDrive and Exchange remain required for those services, and nothing in this split removes them.
Rebuilt automations: Power Automate flows that read or write the list must be rewritten against the new API.

Confirm with your Microsoft account team which licenses are actually retired after the list move, and test every link type before cutover.

Moving SharePoint list data out through CSV export

This sequence turns SharePoint lists into clean tables in Baserow or Grist, with the columns that do not survive a plain CSV export identified and rebuilt on purpose rather than discovered after cutover.

Inventory every list and its columns
The list owner or a site administrator records each list on the site, its item count, its column types, its views, its attached forms and the automations, flows or integrations that read from or write to it. Column types matter most: text, number and date columns map cleanly, while lookup, person, calculated and multi-value choice columns need explicit decisions. Ask the site owner which lists are actively used, because stale lists are often the cheapest to archive instead of migrate. The step is done when you have a single register with one row per list and one row per column, marked by type and dependency.
Export each list to CSV
Export each list from the SharePoint list view, or with a documented export method your administrator confirms for your SharePoint edition, into a dated folder that is named after the list. Open each file and check the header row, the row count against the list footer and the encoding of accented or non-Latin characters. Keep the original export untouched so you can compare against it later. The step is done when every in-scope list has a CSV whose row count matches the source and whose headers match the column register.
Resolve columns that do not carry over as plain values
Lookup and person columns export as display text or identifiers that do not match rows in another table, so you need to decide what each one should become. A lookup usually becomes a link to a second table, which means exporting the target list first and matching on a stable key. Person columns usually become a text column with the email address, or a collaborator field if your Baserow or Grist plan supports the user model you need. Calculated columns should be recreated as formulas after import, and multi-value choice columns should be split into a link or multiple-select field. Record each decision in the register. The step is done when every non-plain column has a written target type and a test row that shows the expected value.
Import the cleaned CSV into the target table
Create the table in the target product, then import the CSV. Baserow's pricing page lists CSV, Excel, XML and JSON import, so a CSV file is the common baseline there. Grist also imports CSV and Excel files. Map each CSV header to a field, set the field type explicitly rather than accepting automatic detection for dates, numbers and choices, and import one list at a time. Note that Baserow's Airtable importer does not apply to SharePoint lists, and this guide does not assume any vendor import tool for SharePoint lists, so the CSV route is the planning baseline. The step is done when each table's row count matches its CSV and sample dates and numbers display as expected.
Rebuild views, forms and automations
Recreate the grid views, filters and sorts that users relied on, then rebuild the forms that fed the list. Compare each rebuilt view against the SharePoint view with the same filter, so the same records appear in both. Rebuild automations as the target product's own automation or as a workflow in a separate tool, depending on your architecture, and confirm each trigger is firing against test data. Automations are the most likely place for silent loss, so list every flow or integration from the inventory and mark it as rebuilt, replaced or retired. The step is done when each view and form returns matching results on the same test records and every inventoried automation has a recorded disposition.
Recreate permissions and access rules
Map each SharePoint list permission to the target: a table or base scope in Baserow, or document and table access in Grist. Baserow lists role-based permissions and audit logs for its Advanced plan, and single sign-on is available on Advanced and Enterprise with an activated license, so confirm which plan you need before you assign roles. Grist connects to an identity provider over OIDC or SAML with an activation key, while forwarded-header authentication and SCIM are available to all editions, so confirm the edition for your directory. Test access with one account per role, including a user who should be denied. The step is done when each role has been tested in both directions and the access matrix is signed off by the list owner.
Test with business users and reconcile data
Give the list owners a copy of the migrated tables and ask them to run their normal tasks for a defined period they agree with you. Reconcile totals, counts and key identifiers between SharePoint and the target, and log every difference with a cause. Confirm that any API consumers now point at the new endpoint and that their responses match the agreed fields. The step is done when owners have signed off in writing on each table and every reconciliation difference is either fixed or accepted with a documented reason.
Cut over and retire the SharePoint lists
Schedule a short freeze on edits to each SharePoint list, run a final CSV export, import only the delta since the last load, and switch users and automations to the new tables. Keep the SharePoint lists read-only for a retention period your records policy sets, rather than deleting them on day one. Ask your compliance lead which retention rules apply to list data before you retire anything. The step is done when the final delta reconciles, users have the new links, and the old lists are read-only with the cutover date recorded in the register.

Rebuilding the automations that depended on the list

Start by treating every consumer of the list as a dependency to be inventoried, because SharePoint list alerts, Power Automate flows and workflow triggers will not move across as-is. Export a complete record of what reads or writes the list: alert subscriptions, flows that start on item created or modified, approval workflows, Power BI or Excel connections, and any custom scripts or third-party tools calling the list endpoints. For each one, record the owner, the trigger, the fields it reads, the fields it writes, and how often it runs. Many of these consumers are forgotten until the list stops updating, so ask the people who built the flows, and check the flow owner accounts in your Microsoft 365 tenant for connections that no one has documented.

Then rebuild each trigger on the target platform. Baserow exposes its data through a REST API and supports webhooks, while Grist offers a REST API with an interactive API console that you can use to test calls before you commit to them. Decide for each consumer whether it becomes a direct API call, a webhook receiver, or a job in an integration tool that you run yourself. Confirm the exact webhook events and payload fields in the current documentation for the version you deploy, since those details are not part of this summary. Grist lists automations and OAuth apps among the features that sit outside grist-core, so if a consumer depends on built-in automation, confirm with the vendor or in a trial whether the edition you need includes it before you plan around it. Also confirm which identity and access controls apply to API tokens for service accounts.

Decide what to retire before you build anything new. Some flows exist only to compensate for SharePoint limits, such as copying a status into an email, and can be dropped once the new tracker sends its own notifications. Others carry approvals or audit obligations that must be preserved, and those need a documented replacement with a named owner, a test case and a cutover date agreed with the business. Run old and new consumers in parallel for a defined period, compare the records each one produces, and switch off the SharePoint side only after the comparison matches. Keep the exported CSV and the flow definitions as evidence of what was retired and why.

Questions teams ask before replacing SharePoint lists

What does replacing SharePoint lists with a self-hosted tool actually cost?

The cost is the sum of components, and most of it is staff time and recurring infrastructure rather than software fees. Self-hosted Baserow and Grist are free to run under their open-source licenses, so the main line items are the application server, a production PostgreSQL database for Baserow, backups, the identity and access setup, and the people who build and maintain the tables and automations. A paid license only enters the picture if you need features outside the open-source edition, such as single sign-on on Baserow's Advanced or Enterprise plans or direct OIDC or SAML connections in Grist, which needs an activation key. Ask any vendor or consultant to quote each component separately, with the license tier named, so you can see which items recur every year.

Which factors make a SharePoint list migration take longer?

Effort rises with the number of lists, the depth of their relationships, and how much logic sits outside the list itself. The biggest drivers are lookup and person columns, because those relationships and user references must be rebuilt by hand in most cases, and automations built in Power Automate or SharePoint workflows, which do not transfer as-is. Permissions complexity also adds work, especially item-level permissions and group nesting that must be mapped to the target tool's roles. A small set of standalone trackers with plain text and choice fields is quick to move. Ask for a list inventory that counts columns, lookups, person fields, views, forms and every flow connected to each list before accepting any estimate.

Can our internal staff replace SharePoint lists without outside help?

Yes, for simple trackers and small databases, a capable team member who knows the business process can rebuild tables, views and forms in Baserow or Grist. The harder part is operating the platform: installing it, connecting it to an identity provider, setting up backups, applying upgrades and monitoring the database. Teams with no container or database experience usually need help on those tasks, and the work is easier to hand off when the platform runs inside your own cloud account or data center. Decide early which tasks you will own after go-live, because that decides whether you need a fixed-scope engagement, a retainer for upgrades and support, or only a one-time setup.

How long does a pilot replacing a few SharePoint lists take?

A pilot's length depends on how many lists it covers, how many automations must be rebuilt, and how quickly the owners can confirm their requirements and test data. No duration figure is supplied for this work, so treat any timeline as provisional until it is written into a scope. A sensible pilot covers one or two lists that have real users, a single identity method, and a defined set of views and forms. Ask the vendor or consultant to name the milestones (inventory, build, test with owners, cutover) and what the client must provide for each, since slow approvals and missing test data usually delay a pilot more than the technical build does.

What do we need from our business owners and IT team for the work?

The work depends on four inputs: a complete list inventory, a named owner for each list, representative test data, and decisions on permissions and retention. The inventory should record fields, lookups, views, forms, permissions and every flow or script that reads or writes the list. Owners must confirm which fields matter, who should see which rows, and what a correct record looks like. Test data should be a sanitized copy of real records so the team can verify imports and automations. IT needs to supply the target environment, the identity provider details and a decision on backup location. Name these responsibilities in the statement of work so that delays can be traced to a specific party.

Is Grist or Baserow the better fit for replacing SharePoint lists?

Choose Baserow when you need a spreadsheet-database hybrid with a headless API, built-in automations and dashboards, and an interface for portals or applications, and when your team is comfortable running PostgreSQL in production. Choose Grist when your lists are closer to relational spreadsheets with heavy formulas, because Grist formulas support full Python syntax and many Excel functions, and its SQLite-based documents are easy to read with standard tools. Both offer a REST API, CSV import and export, and Docker-based installs. Check the features you depend on against each edition's license, since single sign-on and some administration controls sit behind paid tiers in both products. Run both against a few of your real lists before deciding.

How do we move list data out of SharePoint before rebuilding automations?

Export each list to CSV first so the data is preserved independently of the SharePoint workflows, then import it into the target tool and check row counts, person and date fields, and attachments. Attachments and lookups usually need separate handling, since a CSV export does not carry relationships. Rebuild automations only after the data matches, and run both systems in parallel for a short period to compare outputs. Keep a copy of the flow definitions and the original export, because you will need them to confirm behavior after cutover.

Keeping list records and access rules on your own servers

Teams move tracker data out of SharePoint lists for regulated work mainly because the records often hold more sensitive information than the list was ever meant to. Incident registers, vendor onboarding trackers and audit requests carry personal data, attachments and approval history, and the people who own those records need to know exactly where they sit. Self-hosting keeps the records, attachments and permission data inside your own infrastructure, whether that is a cloud account you control, a data center or an isolated network. Before you commit, confirm which systems will hold each class of data, who administers the database and object storage underneath, and whether your data residency terms allow the chosen hosting location.

The exit path matters as much as the entry path. Grist stores each document as a SQLite file, so the numeric and text data can be read by any tool that understands SQLite, which gives you a fallback if the platform changes. Both Baserow and Grist expose REST APIs and export to CSV, and Grist also exports to Excel format, so you can test a full export and re-import into a scratch environment before any decommissioning. Ask the implementation partner to document the export procedure, the attachment handling and the API fields used by each automation, because CSV alone will not carry permissions, comments or formulas in a usable form.

Backup and restore are your responsibility once the platform runs in your environment, and the vendor does not take them over. Plan regular database and attachment backups, test a restore into a separate instance, and record the recovery point you can meet. Retention is a policy decision, not a software setting, so confirm with legal and records management how long tracker entries, attachment versions and audit history must be kept and who approves deletion. Then configure the platform to match, and verify that deletions also reach backups and exports, because a record removed from the live tracker can still sit in an old backup.

How DeployOpen scopes and delivers a list migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For SharePoint lists, that means mapping each list, its views and permissions, and the automations that depend on it to a self-hosted Baserow or Grist deployment before any data moves.

How we scope

Inventory every SharePoint list, its columns, views, item counts and the owners who depend on it.
Identify which lists are trackers, which feed other tools, and which act as lightweight databases.
Agree the written scope, deliverables and timeline in writing before any work starts, as most engagements are fixed-scope.

How we build

Deploy Baserow or Grist in your own cloud account, data center or air-gapped network, with an external PostgreSQL for Baserow where production requires it.
Rebuild views, forms, permissions and identity provider integration, confirming SSO editions and activation requirements for your chosen platform.
Rebuild the API calls and automations that consumed list data, then test each one against the new platform before cutover.

How we hand over

Move list data out through CSV export, verify row counts, field types and attachments against the source before import.
Document the configuration, permission model, API endpoints and backup procedures so your team can operate the platform.
Run a supervised cutover with a documented rollback path, then retire the SharePoint lists only after owners confirm their workflows.

How we support

Provide upgrades, backups and continuous security testing as ongoing retainers after handover.
Keep compliance evidence for access control and change records current, while noting that independent auditors issue any attestation.
Agree support scope, response expectations and upgrade cadence in writing so ownership after go-live is clear.

Open-source alternative to SharePoint lists