What happens to agent websites when they leave?

When an agent leaves a brokerage, their website’s fate follows whoever owns each of its three parts: the domain, the site itself, and the database behind it. Brokerage-provided sites default to staying (minus the agent); agent-purchased sites default to leaving (minus the brokerage’s identity and data agreements). Everything contentious lives in the cases nobody papered — which is most of them.

Three assets, three different answers

Untangle the bundle before arguing about it. The domain belongs to whoever’s registrar account holds it — full stop; neither effort nor fairness moves DNS. The site — design, content, configuration — belongs to whoever owns the platform subscription or paid the build, subject to the brokerage’s brand assets coming out of it. The database — contacts, leads, history — follows the employment or team agreement, overlaid by privacy obligations about what the contacts actually consented to. Disputes almost always come from treating these as one asset called “the website” and discovering at departure that they have three different owners.

The two clean defaults

Brokerage-provided site: the program owns it; the agent’s profile and presence come down at departure, the agent takes what the policy grants — typically their self-sourced contacts and content they personally created — and the site’s slot awaits the next recruit. The full checklist for running this cleanly, including timing and takedown, is agent offboarding and websites. Agent-owned site: it travels with the agent, who must promptly update brokerage identification and re-paper the MLS data feed under the new brokerage — the mechanics from the agent’s chair are covered in what happens to my website when I switch brokerages. The perennial ambiguity is the middle case: sites the brokerage “arranged” on a vendor account, paid by the agent, branded by both. That middle case is a policy vacuum, and vacuums litigate badly.

Write the policy at onboarding, not offboarding

Every question above is cheap to answer while everyone likes each other. A complete portability policy fits on one page: who owns the domain; who owns the subscription and at what point an agent may convert it to personal ownership; what content each party keeps; how the database divides and in what export format; and the deadline for identity changes after departure. Ownership fundamentals from the agent’s perspective — worth reading before signing anything — live at do I own my real estate website.

Portability as a recruiting asset

Counterintuitive but consistently true: brokerages with generous, written exit terms recruit better with provided technology, not worse. Agents evaluating a provided-site program price the exit risk — “what do I lose if this doesn’t work out?” — and a clear, fair answer removes the objection entirely, while hostage-taking stories circulate in every agent community. Fair terms cost the brokerage little in practice: departing agents were departing regardless, and the program’s value was never the leverage of trapping them. The programs that get this right, described in agent websites for brokerages, treat portability as a feature of the pitch.

Make the mechanics trivial

Policy is half; tooling is the rest. On a well-structured platform, offboarding is an account operation: access ends the day the seat closes, contact exports generate in standard formats, and — where the policy allows — a provided site moves to the agent’s own billing without a rebuild. BrokerFold’s account and seat structure keeps those seams clean, which turns the worst week of a brokerage relationship into administration instead of archaeology. Review the policy against the tooling once a year: offboarding terms drift out of sync with what the systems can actually execute, and the gap only ever gets discovered during a departure.