CRM EXIT by Move Big Rocks Build my business case

CRM Exit by Move Big Rocks

See the destination before evaluating it

Move Big Rocks is a self-hosted operational platform, not a promise that every HubSpot or Salesforce capability maps directly. CRM Exit evaluates it alongside staying, right-sizing, another SaaS CRM, and a bespoke build.

This page describes public source version v0.21.3, reviewed 12 July 2026. The repository and running instance continue to change; project proposals pin the version and extensions actually evaluated.

Build my exit business case

01

Product evidence

These screenshots come from running Move Big Rocks product surfaces. They demonstrate implemented interfaces, not migration scale or customer outcomes.

Core administration

Move Big Rocks administration dashboard

Workspace administration, operational navigation, and installed product surfaces share one authenticated platform.

Operational health

Move Big Rocks system metrics dashboard

The operational-health surface exposes runtime signals for an owned deployment. The monitoring and alerting scope still needs to be agreed for each production operating model.

Extension example

Move Big Rocks web analytics extension dashboard

Web analytics is a service-backed extension using the same workspace, lifecycle, routing, and administration boundaries as the core platform.

02

Core data model

Move Big Rocks core owns shared operational primitives so each extension does not create another isolated product silo.

  • Workspace: tenant and security boundary within an instance.
  • Team and membership: operational ownership and access boundary inside a workspace.
  • Service catalog node: definition of work the organization accepts and routes.
  • Form spec and submission: structured intake, validation, and collected evidence.
  • Queue and queue item: where operational work waits and is assigned.
  • Conversation: a live interaction that can resolve or become durable work.
  • Case: durable work with contact, ownership, status, priority, SLA, communication, and follow-through.
  • Contact: the external person connected to conversations and cases.
  • Knowledge resource: Markdown content governed by versioned concept definitions and audience controls.
  • Concept spec: structured definitions for RFCs, templates, skills, goals, strategies, milestones, workstreams, and other knowledge types.
  • Attachment: files associated with forms, cases, or knowledge, subject to configured storage controls.
  • Automation: event-driven rules and actions.
  • Agent: a first-class principal with workspace-scoped credentials and auditability.

Core relations are stored in PostgreSQL bounded-context schemas. GraphQL and the mbr CLI expose the same service contracts to human interfaces and agents.

03

Implemented core feature surface

  • Authentication, workspaces, teams, memberships, and agent identities.
  • Contacts, service catalog, structured forms, submissions, and public form intake.
  • Queues, conversations, cases, labels, assignment, and communication records.
  • Markdown knowledge and versioned concept specifications with audience rules.
  • Attachments, automation, event publication, and auditable service operations.
  • GraphQL API, JSON-capable CLI, admin interface, public routes, and machine-readable discovery.
  • PostgreSQL-backed runtime, object-storage and email-provider integration points, health routes, and blue-green deployment support.
  • Signed, versioned extension lifecycle with manifest, permission, endpoint, migration, health, and activation controls.

04

Extension architecture

Extensions add specialized products while reusing core identity, tenancy, cases, contacts, forms, knowledge, events, and agents.

Each bundle declares its publisher, version, scope, risk level, permissions, owned entities, database migrations, routes, scheduled work, command catalog, agent skills, lifecycle hooks, and endpoint policies. Core validates and mounts approved surfaces rather than allowing unrestricted in-process plugins.

Two runtime classes

  • Bundle extensions: configuration, concepts, forms, knowledge, public assets, routes, and workflows built primarily from shared primitives.
  • Service-backed extensions: isolated services for custom handlers, ingest, scheduled jobs, event consumers, richer administration, or specialized storage and behavior.

Service-backed extensions expose internal health endpoints. Core retains control of external routing, authentication, workspace binding, rate limiting, body limits, tracing, activation, and supervision. Extension-owned structured state lives in its own ext_* PostgreSQL schema.

Public first-party product areas

The public extensions repository contains ATS, community feature requests, enterprise access, error tracking, sales pipeline, and web analytics product areas. Availability in a customer instance depends on the pinned bundle, maturity review, configuration, and agreed support scope; repository presence alone is not a production-readiness claim.

05

Capability boundary today

Move Big Rocks currently provides operational core primitives and installable product extensions. It does not claim automatic feature parity with an arbitrary CRM estate.

What it can be evaluated for

  • Customer and contact-centered operational records.
  • Structured intake, service catalogs, queues, conversations, and cases.
  • Team-owned knowledge, strategic context, forms, automation, and agent-assisted operation.
  • Sales-pipeline and other product workflows when the relevant extension is installed and verified.
  • Customer-controlled self-hosting and a managed operating proposal where offered by Move Big Rocks BV.

What requires migration-specific work

  • Source-object mapping, historical coverage, files, associations, owners, and permissions.
  • Workflow reconstruction and behavioral equivalence.
  • Reports, dashboards, integrations, identity, email, storage, and downstream system changes.
  • Data-quality remediation, reconciliation, cutover, rollback, training, and handover.
  • Custom extension work for requirements not provided by core or a verified extension.

What is not implied

  • Native execution of Salesforce Apex, Flow, managed packages, or every Salesforce cloud product.
  • Native replacement of HubSpot marketing automation, advertising, content, or every hub feature.
  • A vendor-hosted public sandbox; the current evaluation path is a local or customer-controlled deployment.
  • A one-click migration, zero downtime, complete source API coverage, or automatic workflow equivalence.
  • Compliance certification or production readiness outside the precise version, infrastructure, controls, and service scope reviewed for a project.

06

Licence and self-hosting rights

Move Big Rocks core is source-available under the MBR Source Code Available License 1.0. It is not an open-source licence.

The licence permits an organization to self-host, use, copy, modify, and build private extensions for its own internal business operations. Without written permission from Move Big Rocks BV, it does not permit selling the platform or extensions, selling access to them, or offering them as a hosted or managed service. The repository LICENSE file is the governing text.

07

Deployment and ownership

The current owned deployment path uses a private instance repository and a pinned Move Big Rocks release on customer-controlled Linux infrastructure. A production design must define PostgreSQL, object storage, email, TLS, backups, restoration tests, monitoring, updates, incident handling, retention, and support responsibilities.

Self-hosting transfers operational responsibility; it does not make that work disappear. A managed proposal identifies which responsibilities Move Big Rocks accepts and how data export and operational handover work.

Compare MBR in my business case

Make the next decision

Build the evidence before committing to the exit.

Build my exit business case Request a CRM Exit Audit