Whose licence is the site running on when the client leaves

The renewal notice is a small administrative event that arrives in the wrong inbox. A site has been running for a year on a licence its studio bought. Nobody decided this: the licence covered unlimited websites, one more installation cost nothing, and the build was quoted by the hour. The first time anyone asks whose licence the site is on tends to be the year the client asks what the money is for.

The tension is that an unlimited-site licence is good for the studio and ambiguous for the client. It makes every extra site cheap to launch, which is why studios standardise on one. It also puts the client's most important software asset in somebody else's account, renewed on somebody else's schedule. The site is fine while the relationship lasts. The failure comes later, and it is not that the site falls over: nobody is left holding what keeps it current.

What follows is an argument about contracts, not a verdict on the builder.

An unlimited licence covers sites, not the people who bought them

Elegant Themes' pricing page, published on 19 October 2026, sells Divi, the theme and builder, at $89 billed yearly and $249 one-time, both covering unlimited websites. Prices change, so quote them from the page rather than an old proposal. That price line is the whole licensing decision for most studios: one purchase covers any number of installations.

The client's site is one of those installations. It runs under the studio's licence rather than one of its own, so the renewal that keeps it current is an event in the studio's account. Nothing about that is underhanded, and for a site the studio maintains for years it is the right arrangement. It becomes a problem when the relationship ends, because the licence does not end with it.

What the client keeps is the files and the database. What goes is the account that receives new versions. No error page marks the day the renewal stops, and no notice lands on the client's desk. The site stops being updated while its owner believes it is maintained.

Three arrangements, and what each one costs in year two

Every version of this problem is one of three arrangements. They differ less in price than in who makes the renewal decision, which is what matters when the relationship sours.

The studio holds the licence

Year one is simple: the licence sits inside the build price, or goes unmentioned. Year two shows it. Either the studio renews and passes the cost on, so the client pays for a licence they cannot open, or the studio does not renew and the update path stops without anyone saying so. Neither is dishonest on the day, and both are hard to unpick later: the client has no account to log into and no renewal date of their own.

The client buys their own

This is the arrangement that survives the relationship. The client's card is on the renewal, the client's account receives whatever the licence delivers, and the studio keeps building without silently supplying the software underneath. The year-two cost becomes visible and small: $89 on the yearly licence, nothing on the licence line if they took the $249 option. The risk moves: a client who is not reminded will let the renewal lapse. A date in the handover document and a reminder on both calendars cost less than the argument.

The site changes hands with a licence

Transfer sounds like the tidy option and is usually the least tidy. A licence sold as unlimited website usage has no per-site licence inside it to detach, so there is nothing small to hand over. The client buys a licence at the moment of exit, which is the previous arrangement under worse conditions, or the studio's whole account changes hands, which reaches every other site under it and is a decision no single client should be asked to make.

Whether an account or licence can move to another owner is decided by the vendor's terms, not by the contract between studio and client. That is the first thing to read and the last thing to assume. A contract that promises a transfer the vendor forbids is a clause waiting to be discovered at the worst moment.

If the argument has landed where it usually does, with the client holding the licence, the number belongs in the proposal rather than in a later email: Elegant Themes' pricing page lists Divi at $89 billed yearly and $249 for a lifetime licence, both covering unlimited websites, and the page is the authority on both figures because prices change.

The break-even is arithmetic; the ownership question is not

At $89 a year, the $249 one-time option pays for itself after 2.8 years. Elegant Themes' comparison table on the pricing page, published on 19 October 2026, makes the same case: one year at $89, ten years at $249. Two conditions belong next to the figure. It compares list prices on one date, and a yearly licence can be repriced at any renewal. The one-time option also does not make the whole account one-time: the same page lists Divi Pro at $277 billed yearly and a lifetime-plus-pro arrangement at $297 today followed by $212 a year for the pro services. A client who needs the theme and builder, not the pro services, should not be handed the second arrangement by default.

The arithmetic hides the asymmetry. The party holding the licence holds the renewal decision, which is the stronger position when there is a disagreement. A client whose site runs on the studio's licence cannot renew it, cannot see the date, and cannot take it to the next developer without asking. A studio that hands over the licence gives up a little control and gains a clean answer to the question this piece opened with.

The clause to sign before the first invoice

None of this needs a lawyer to draft, though it should be read by one. What follows is a starting point, not legal advice, and the vendor's terms govern what the licence permits. The purpose is to turn ownership into a decision instead of an inheritance.

The website's page builder licence is purchased in the Client's name and belongs to the Client from the date of purchase. The Agency's build, templates and configuration are supplied for use on this website only. The Client is responsible for the licence renewal from the date recorded in the handover document, and the Agency will remind the Client in writing thirty days before that date. If the licence is not renewed, the Agency's obligation to supply builder updates ends with it. On termination for any reason, the Agency delivers account access, a licence inventory and a current backup within ten working days. This agreement does not transfer any other licence, account or subscription held by the Agency.

It names the holder and the renewal date, makes handover an artefact with a deadline, and keeps the studio's other licences out of the transfer.

The clause is deliberately dull, because dull clauses get signed. One that explains the whole model gets shortened into something weaker.

A handover is an inventory, and the inventory has a query

Once the licence is settled, the studio still has to say what it is handing over. The licence is one line. The build is everything else, and the build is where ownership returns in a form nobody put in the contract.

Global library items are the clearest example. Elegant Themes' documentation defines one as a Module, Row or Section that appears the same on whatever pages it is added to, and says that editing it changes every page that uses it. A studio that maintains a shared set across client sites has kept a piece of the build process after handover: the client owns the licence and the studio still changes their pages. That is legitimate, but it has to be named in the handover pack, or the next edit looks like somebody working on a site they no longer maintain.

The second thing to inventory is the storage format, because it decides what the next developer receives. Divi 4 stored a page as shortcodes in the post content, of the form [et_pb_text ...]. Divi 5 uses a block-based framework that does not use shortcodes. A site handed over in the older format sits on shortcodes rather than blocks, and the route between the two formats belongs to the vendor.

Elegant Themes' documentation for the Divi 5 Migrator says it converts supported modules, and states that modules not yet supported continue to run wrapped in the Divi 4 framework, and that a page containing one of them loads the Divi 4 framework for that page, which they say can affect performance. The caveat is theirs and belongs in the handover unsoftened. For pricing, a migration is a project with an inventory and a test period, not an administrative step.

Run this against the database before quoting that handover. It lists published posts and pages that still store the old shortcode format.

SELECT ID, post_title
FROM wp_posts
WHERE post_status = 'publish'
  AND post_type IN ('post', 'page')
  AND post_content LIKE '%[et_pb_%';

Check the table prefix in wp-config.php rather than assuming wp_. An empty result does not prove a site is on Divi 5; it proves that none of the published posts and pages checked store the old shortcode format. Anything kept outside post content will not appear, so treat the output as one line of the inventory.

The other half is a set of questions for the vendor, the same for any builder: which account receives the renewal notice and the update notifications, whether a licence or account can be moved to another owner, and what happens to updates and support when a renewal stops. Ask in writing before the proposal. The answers belong in the contract, not in a memory of a support chat.

The default worth writing down

The default is the one this article has been arguing towards. The client owns the licence. The studio owns the build process: the templates, the global items, the patterns, the handover pack. Handover is a line item with a price and a deadline, quoted like any other part of the job. This is not legal advice, and the vendor's terms govern what a licence permits.

One case supports the studio holding the licence, and it is narrower than it sounds: a retainer where the studio is the maintainer, the client has agreed in writing what happens on exit, and the renewal sits inside a fee the client already pays. Even then the exit procedure has to exist before it is needed. The arrangement is defensible only because somebody wrote down how it ends.

If the client will still own the site in three years, they should own the licence now, and at current prices the one-time option has paid for itself inside that window. If the relationship might not survive the year, they should own it anyway, because the alternative is discovering the problem during the exit. If the studio is asked to hold it, the answer is yes only with a named exit procedure and a date attached. That is the rule: the client owns the licence, the studio owns the build, and the handover is a line item, not an argument.