Sharetribe Flex Migration Guide: Moving from Sharetribe Go (Community Edition) to Headless Flex

Direct Answer: Migrating from Sharetribe Go (Community Edition) to Sharetribe Flex requires bridging a legacy monolithic PHP/MySQL schema to a decoupled, API-first architecture. This architectural shift involves schema normalization, event-driven data ingestion via the Flex Integration API, and a custom frontend built with modern frameworks.

For marketplace operators and engineering leaders, the end-of-life of Sharetribe Go (formerly Community Edition) presents an urgent architectural challenge. Moving away from a monolithic, self-hosted PHP application to Sharetribe Flex’s serverless, API-first architecture unlocks infinite scalability, modern payment infrastructure, and enterprise-grade extensibility. However, it requires a carefully orchestrated data migration and integration pipeline.

At TechVinta, our Principal Solutions Architects specialize in complex marketplace transformations. We bridge legacy systems to modern tech stacks with zero business disruption, offering 4 to 6 hours of daily US timezone overlap to ensure seamless, real-time collaboration with your internal product and engineering teams.

The Sharetribe Go vs. Sharetribe Flex Architectural Paradigm Shift

Sharetribe Go is a monolithic PHP application relying on a deeply coupled MySQL relational database schema. Users, listings, transactions, and messages exist in static relational tables with hardcoded business logic. Conversely, Sharetribe Flex separates concerns entirely into two distinct layers:

• Flex Console & Core API: A managed backend handling core marketplace primitives (Users, Listings, Transactions, Availability) via secure REST endpoints and an immutable event stream.
• Integration API: A high-throughput, read-heavy query engine designed for ETL pipelines, advanced search indexing (e.g., Elasticsearch/Algolia), and deep asynchronous integrations.
• Custom Client App: A decoupled frontend (React, Next.js, or Remix) communicating with the Flex Marketplace API and third-party services.

Because Flex abstracts database-level operations behind its API, you cannot execute raw SQL migrations. Instead, data must be systematically ingested using programmatic batching, rate-limit management, and transactional payload mapping.

Phase 1: Database Extraction and Schema Mapping from MySQL to Flex

The first technical hurdle is normalizing legacy MySQL data into the JSON-friendly entity models required by Flex. Go’s relational tables—such as people, listings, transactions, and community_custom_fields—must be mapped to Flex Extended Data structures.

Below is a production-grade Ruby on Rails 8 migration script template utilizing the official sharetribe_flex_integrations client. This script extracts legacy users, normalizes their profiles, and safely provisions them inside the Flex ecosystem while preserving legacy identifiers for referential integrity.

# frozen_string_literal: true

require "mysql2"
require "sharetribe_flex_integrations"

class FlexUserMigrator
  BATCH_SIZE = 100

  def initialize
    @mysql_client = Mysql2::Client.new(
      host: ENV.fetch("LEGACY_DB_HOST"),
      username: ENV.fetch("LEGACY_DB_USER"),
      password: ENV.fetch("LEGACY_DB_PASS"),
      database: ENV.fetch("LEGACY_DB_NAME")
    )
    
    SharetribeFlexIntegrations.configure do |config|
      config.client_id = ENV.fetch("FLEX_CLIENT_ID")
      config.client_secret = ENV.fetch("FLEX_CLIENT_SECRET")
      config.integration_api_base_url = "https://flex-integ-api.sharetribe.com"
    end
    
    @client = SharetribeFlexIntegrations::Client.new
  end

  def migrate!
    offset = 0
    loop do
      users = @mysql_client.query("SELECT * FROM people LIMIT #{BATCH_SIZE} OFFSET #{offset}")
      break if users.count.zero?

      users.each do |legacy_user|
        process_user(legacy_user)
      end

      offset += BATCH_SIZE
      sleep(0.5) # Respect API rate limits
    end
  end

  private

  def process_user(legacy_user)
    payload = {
      email: legacy_user["email"],
      first_name: legacy_user["given_name"],
      last_name: legacy_user["family_name"],
      protected_data: {
        legacy_person_id: legacy_user["id"]
      },
      public_data: {
        migrated_from_go: true,
        bio: legacy_user["description"]
      }
    }

    # Ingestion via Integration API / Admin SDK pattern
    response = @client.post("/v1/integration_api/users/create", payload)
    
    if response.success?
      Rails.logger.info("Successfully migrated user: #{legacy_user['email']}")
    else
      Rails.logger.error("Failed user #{legacy_user['email']}: #{response.error_message}")
    end
  end
end

Phase 2: Migrating Transactions, Listings, and Conversations

Migrating listings and transactional history is exponentially more complex than user provisioning due to foreign key dependencies and state machine validations. In Sharetribe Go, listings contain custom fields stored across EAV (Entity-Attribute-Value) tables. In Flex, these map directly to publicData or metadata JSON attributes on the Listing entity.

Furthermore, historical transactions in Go cannot simply be injected into Flex as "closed" states without bypassing the Flex Transition Engine. To maintain audit trails without breaking business logic:

• Provision historical transactions with a migrated_historical_record: true flag inside protected metadata.
• Ensure financial ledger entries reconcile properly by matching historical payout identifiers with Stripe Connect customer mappings.
• Reconstruct message threads using the Flex Messages API, mapping legacy author IDs to newly generated Flex user UUIDs.

Comprehensive 2026 Architectural & Financial Comparison

When planning your migration roadmap, weighing the technical capabilities, operational overhead, and financial commitment is vital. The matrix below outlines realistic projections for modernizing a legacy Sharetribe Go instance.

Partner with TechVinta for Seamless Marketplace Modernization

Migrating away from Sharetribe Go is not merely a technical database script—it is a critical evolution of your product's underlying infrastructure. Attempting this transition without deep domain expertise risks data corruption, broken payment states, and catastrophic downtime.

At TechVinta, our elite team of distributed systems engineers, backend architects, and frontend developers handle end-to-end Flex migrations. With rigorous code standards, automated testing pipelines, and 4 to 6 hours of guaranteed daily US timezone overlap, we integrate directly with your product roadmap. Contact our Solutions Architecture team today to schedule a technical discovery audit for your marketplace.

Frequently Asked Questions

Can I directly import my Sharetribe Go MySQL database into Sharetribe Flex via a SQL dump?

No. Sharetribe Flex utilizes a cloud-native, multi-tenant serverless architecture with a completely abstracted data layer. Direct SQL ingestion is impossible. Data must be meticulously extracted, cleaned, and ingested programmatically through authenticated REST requests using the Sharetribe Flex Integration API or Admin SDK.

What happens to active user passwords and authentication credentials during the migration?

Due to cryptographic hashing differences and security protocols, legacy plain-text or salted passwords from MySQL cannot be directly imported into Flex Auth. The standard migration protocol requires generating secure password-reset tokens or prompting users to execute a streamlined password-reset flow upon their first login to the new Flex-powered frontend.

How does TechVinta handle custom extensions built into our legacy Sharetribe Go codebase?

During our initial architectural discovery phase, TechVinta engineers audit all legacy PHP modifications and custom plugins. We then re-architect those business requirements into modern, decoupled microservices or leverage Flex's native Extended Data capabilities and third-party webhooks to replicate or enhance original functionality within the new stack.