Migrating local → Enterprise

You’ve been running local PLUR. Your team just stood up Enterprise. This guide walks the move — what to migrate, what to keep local, and how the two coexist.

The mental model

You don’t replace local PLUR with Enterprise. You add Enterprise as a remote store. Your local PLUR keeps working; new shared scopes show up alongside personal ones. Most of your engrams stay local.

~/.plur/           ← still your local store, untouched
  + remote store "acme" → https://plur.your-org.com
    └─ scopes: group:acme/* , org:acme , (and project: scopes the team shares)

A recall in a project with shared scope visible to you returns local engrams and server engrams, ranked together.

Step 1 — connect

Get an API key from your Enterprise server’s /me/api-keys (see Authentication). Then:

plur stores add \
  --name acme \
  --url https://plur.your-org.com \
  --token plur_sk_...

Verify:

plur stores list
plur status --store acme

You should see your name, your group memberships, and an engram count.

Step 2 — decide what to migrate

The principle: migrate what generalises, keep what’s personal.

Local engram	Where it should go
”Always validate input at API boundaries”	`org:acme` or `global` (depending on scope)
“Our deploys go through Caddy”	`group:acme/platform`
”I prefer terse responses”	Stays local in `user:gregor`
”Project X uses old auth lib”	`project:x` (mirror on Enterprise if the project is shared)

Don’t migrate everything in one go. Start with one scope — usually org:acme or group:acme/<your-team> — and 10–20 engrams. See how it lands.

Step 3 — export as a pack

The pack is the migration unit:

plur packs export \
  --ids ENG-2026-0301-001,ENG-2026-0315-008,ENG-2026-0402-022 \
  --out ./acme-onboarding \
  --version 1.0.0 \
  --target-scope group:acme/platform

Review:

plur packs preview ./acme-onboarding

You’ll see the statements, types, and the scope they’ll land in. Adjust until it looks right.

Step 4 — import into Enterprise

plur packs install ./acme-onboarding --store acme

The Enterprise server checks that you have write access to group:acme/platform. If you don’t, you get 403 and need either a teammate with editor+ in that group to install, or an admin to grant you access.

Conflicts (same id already on the server) are flagged for review — install never silently overwrites.

Step 5 — verify with a teammate

Have someone else on your team — already connected to acme — run:

plur recall --store acme --scope group:acme/platform "deploy"

The engrams you just migrated should appear in their results. If they don’t, double-check target_scope in the pack manifest matches a scope they can read.

After migration

Future engrams

New engrams you want to share with the team go directly to Enterprise — no need to do the local-then-export dance. In a project with a .plur.yaml like:

scope:  group:acme/platform
domain: platform
store:  acme

…hooks send corrections to the Enterprise server automatically.

Local stays local

Your global, project:*, and user:* engrams keep living in ~/.plur/. Sync them across your own machines with plur sync (git remote) as before. The two systems don’t interfere.

Reverse migration

Pull team engrams into your local PLUR for offline work:

plur packs export --scope group:acme/platform --out ./team-snapshot --version snapshot --store acme
plur packs install ./team-snapshot

Now you have a local copy of the team’s engrams. Useful on a plane or in places with bad connectivity.

Common pitfalls

Migrating too eagerly. Resist the urge to push your whole local store. 90% of personal engrams belong in user: and add noise to a shared scope.
Wrong target scope. Easier to widen later than narrow — start with group: rather than org:.
Forgetting hook config. Without .plur.yaml, new corrections still go to ~/.plur/. Update each project’s .plur.yaml after migration.
Pinning local engrams. pinned: true doesn’t transfer; pinning is an Enterprise admin action, not a pack field. Re-pin after install if needed.

When to move everything

If your entire team is on Enterprise and you don’t want a local store at all, plur init --no-local --store acme makes the Enterprise server your default. Local commands proxy to the server; hooks write directly to Enterprise. Saves a tiny amount of disk and removes one place where state lives, but the trade-off is no offline mode.

Most users keep both. The two-tier setup is the supported default.