Replacing a Supabase or Firebase backend after moving to WordPress

Why the backend is a separate project

Many websites built with Lovable, Bolt, Replit or Cursor use Supabase or Firebase for authentication, data storage and file uploads. The frontend that visitors see is React; the data lives in a hosted PostgreSQL or NoSQL database protected by security rules. A website converter reads the rendered frontend and turns it into WordPress pages and a theme. It does not and should not copy database tables, authentication users or security policies, because those are application infrastructure rather than page content.

Treating the backend as a separate workstream is good engineering. It forces a conscious decision for every dynamic feature: keep it running as an external service, replace it with a WordPress plugin, or remove it because it is no longer needed. In most small and medium websites the answer is surprisingly simple, because the majority of backend usage consists of forms, newsletter sign-ups and a handful of protected pages.

Inventory: map every dynamic feature

Start with a written inventory. Open the original app and list each place where data is read or written: contact forms, quote requests, login and registration, user dashboards, uploads, comments, bookings, payments and any admin screens. For each feature note who uses it, how often, which data fields are involved and whether existing records must be preserved.

This inventory usually reveals three categories. First, simple data capture such as forms, which maps directly to a form plugin. Second, user accounts and protected content, which map to WordPress users, roles and a membership plugin. Third, genuine application logic such as a custom calculator, a SaaS dashboard or real-time collaboration, which either stays as an external app or becomes a dedicated custom plugin.

Forms and data capture

Contact, quote and application forms are the most common backend feature. A mature form plugin stores entries in the WordPress database, sends notification emails, supports spam protection, file uploads, conditional fields and exports to CSV. Integrations with CRM and email marketing tools are available out of the box or through webhooks.

For reliable email delivery configure an SMTP plugin with a transactional email provider and set up SPF, DKIM and DMARC records for the sending domain. This step is frequently forgotten and is the main reason form notifications land in spam after a migration.

Authentication, users and roles

Supabase Auth and Firebase Auth store users with hashed passwords that cannot simply be imported into WordPress in a portable way. The practical route is to import user records, names and email addresses, and ask users to set a new password through a reset email on first login. A membership or user registration plugin provides login, registration, profile pages and content restriction.

WordPress roles and capabilities replace row-level security rules. Define roles carefully, never give editors administrator rights, and restrict protected pages by role. Social login with Google or other providers is available through established plugins if the original app used it.

Database content and custom data

Data that is really content, for example articles, products, locations or listings stored in a Supabase table, should become WordPress posts or a custom post type with custom fields. Export the table to CSV and import it with an import plugin, mapping columns to titles, content, taxonomy terms and meta fields. After import the data is editable in the dashboard and can be displayed with block templates.

Data that is truly operational, such as transactions, telemetry or complex relational records, often belongs in the existing external database. WordPress can read it through a REST API or a small custom plugin. This hybrid architecture keeps WordPress responsible for presentation and content while the specialised service remains responsible for the application data.

File storage and media

Images and documents stored in Supabase Storage or Firebase Storage can be downloaded in bulk and imported into the WordPress media library. For large libraries an offload plugin can keep files in object storage while WordPress manages references and thumbnails. Make sure filenames and alt texts are meaningful, because image search and accessibility both depend on them.

Payments, bookings and integrations

Stripe checkouts coded into an AI app are replaced by WooCommerce or a dedicated payment plugin with the same Stripe account. Booking systems become a booking plugin or an embedded scheduling service. Webhooks that previously triggered serverless functions can be received by a WordPress REST endpoint or by an automation platform. Each of these replacements is a standard, well-documented WordPress pattern.

Security and compliance

Moving data means taking responsibility for it. Use HTTPS everywhere, limit administrator accounts, enable two-factor authentication, keep plugins updated and schedule encrypted off-site backups. Review the privacy policy so it reflects the new processors, and delete data from the old backend once the migration has been verified and retention requirements allow it.

Expert conclusion

Convert2WP converts the visible website: pages, layout, text, images and design. Backends are not converted, and that is the correct boundary. With a clear inventory, a form plugin, a membership plugin, optional WooCommerce and careful data import, almost every Supabase or Firebase feature of a typical marketing or business site is replaced within days. Small glitches during this phase are normal and are fixed afterwards, often with nothing more than a plugin setting.