Most Monospace features come from me hitting a wall using the app.
This one came from a boring moment: I had a project sitting in my personal space that clearly belonged in an org with other teammates. I knew it didn't make sense where it was. And I couldn't move it. You couldn't, either.
So I built the thing I wanted to click.
What it does
Open any project you admin, go to Project Settings → Danger Zone, and click Move project. A wizard pops up with four steps:
- Pick a target — any org where you're an owner or admin, or your personal space.
- Review what moves and what resets — a clear green/amber split so you know exactly what's coming with the project and what'll be wiped.
- Confirm slug and owner — if there's a slug collision in the target, you get a pre-filled alternate you can tweak.
- Type to confirm — a phrase like
move ProjectName to TargetOrg, exact match required. No accidental moves.
Then it actually moves — the project card arcs between the two org pills in the modal, and on the sidebar, your project glides into its new section with a springy bounce, an accent-colored ring pulse, and a burst of sparkles. Slightly over the top on purpose. Feature deserves a little theatre.
What travels with the project
Everything. Boards, tasks, notes, links, chat history, ticket inbox, calendar items, subscriptions, purchase orders, GitHub and Vercel connections, custom email domains, files — all of it rides along via the project's internal ID, not the org it used to be in. No re-upload, no re-connect, no lost messages.
What gets reset (and why)
Permissions. Role overrides and section grants are specific to the old org's roles — those role IDs don't exist in the new org, so trying to preserve them would either fail silently or grant access to the wrong people. Safer to reset. The project inherits the target org's default grants, and you re-grant anything custom from scratch. Takes a minute, zero surprises.
Ownership. Every project has one owner, and that owner has to be a member of the org it lives in. If the current owner isn't a member of the target, they can't remain the owner. So ownership auto-switches to the target org's owner. Clean, unambiguous.
Plan mismatch — the clever bit
Here's where I had to make a call. What if the project has features enabled that the target org's plan doesn't include? Say you're moving a project with GitHub, Vercel, and the Maintenance scheduler all on — but the target is on a Starter plan that doesn't include any of those.
Three options: block the move, silently turn the features off, or something smarter.
I went with smarter. The feature flags on the project stay exactly where they are. The target org's sidebar just hides items that aren't in its plan. So nothing is destroyed — if the target org later upgrades, every feature pops back on automatically, exactly how it was. No data loss, no reconfiguration, no "you need to re-enable X" messages.
The review screen warns you about this up front, with a list of the specific features that'll be hidden until the target upgrades.
Keep users on the same spot
If you were looking at /old-org/my-project/notes/abc-123 when you clicked Move, you don't get bounced to the project homepage after. The URL just swaps the org slug and you land on the same note in the new org. Section, item, everything preserved. The only thing that changed is which org you're looking at the project through.
Personal ↔ Org both ways
You can promote a personal project to an org, or demote an org project back to your personal space. Same flow, same guarantees. Useful if you start a project as a solo experiment and want to pull collaborators in later — or if you need to pull something out of an org into a quiet space.
Who can do this
Admin or owner of both the source and the target. Members can't move projects out, and random admins can't dump projects into orgs they only lightly belong to. The target-picker only shows orgs you have admin rights in, so you won't even be tempted.
If you're moving to personal, only the current project owner can do it.
The animation, because I need to talk about it
OK. Two animations fire at once.
Inside the modal, a small card with the project's emoji and name arcs between two org pills — source on the left fading dim, target on the right pulsing with an accent ring as the card lands. Particle trail following behind. Kind of like a Mario power-up if Mario was a SaaS app.
On the sidebar, at the same time, your actual project row uses Framer Motion's shared-layout detection to glide from its old spot in the source section to its new spot in the target section. Not a pop, a real spring-loaded travel — you can see it move up or down the sidebar. Then a scale bounce, an expanding ring, and a sparkle burst at the landing spot.
Total runtime is about 2 seconds. It's the most fun part of the whole feature.
Why this matters
Orgs in Monospace aren't just cosmetic. They're access boundaries. The list of people who can see a project is the org's member list. So moving a project from org A to org B fundamentally changes who has access — which means it has to be deliberate, auditable, and reversible if needed.
You can move it back. The audit trail shows who moved it, when, and in which direction. And since the internal project ID never changes, all your links still work — we redirect the URL for you, but any integration pointing at the project by ID keeps working untouched.
This is live on all plans that include orgs — Team and up. If you're a solo user, the personal-to-personal move doesn't apply, but you can still receive a project moved into your personal space from any org you admin.
Go move something. I dare you to sit through the animation without smiling.
— Cam