What decides the destination

Chapter 2 produced an inventory. It is a long document, and most of it will not change your destination.

That is the uncomfortable part. Two organisations can hand you inventories that look alike, the same version, a similar number of sites, volumes within a few hundred gigabytes of each other, and the right answer for one of them is not the right answer for the other. The difference is never in the totals. It is in four or five facts that were on page six.

This chapter separates those facts from the rest. It does not choose a destination, and it will not tell you which one is better. That is chapter 4, and it is only answerable once you know which of your facts are load-bearing.

Not every fact has the same weight

The numbers that get quoted in the first meeting are usually the ones that decide the least.

Content volume. Two terabytes is not a destination question. It is a schedule question: it tells you how many waves you need and how long each one takes. The same is true of item counts, with one exception that chapter 2 already recorded, which is that some individual limits behave differently at either end and have to be checked per destination rather than in aggregate.

Number of sites and site collections. A thousand sites and eighty sites take different amounts of effort and produce the same set of destination options. What matters is not how many there are, but whether any of them depends on something that does not exist at the destination.

Number of users. This shapes licensing, communication and training. We have not seen it eliminate a destination, and we would be careful of any argument that says it does.

Number of farms. This decides whether you are running one project or several. It rarely decides where they go.

None of these are unimportant. They are the difference between a nine-month project and an eighteen-month one, and getting them wrong is expensive. But if you are trying to answer "Subscription Edition, SharePoint Online, or hybrid", they will not answer it for you, and a workshop that spends its time on them will end without a decision.

Hard constraints: the facts that remove an option

A hard constraint does not make a destination expensive. It removes it. There are fewer of these than people expect, and they are worth finding first, because everything else is negotiable and these are not.

Server-side code that has to keep running. Full-trust farm solutions run on the SharePoint servers and call the server object model. Microsoft's own documentation is unambiguous about where they can live: farm solutions "are supported in SharePoint on-premises only", and "cannot be installed on SharePoint Online" (development models, add-ins compared with solutions, checked on 4 August 2026). If a full-trust solution is activated somewhere that matters and cannot be rewritten inside your budget, SharePoint Online is not on your list for that content. Note the two qualifiers, because they are where the real work is: somewhere that matters, and cannot be rewritten. Chapter 2 asked you to record where customisations are activated rather than where they are installed for exactly this moment.

Data that has to stay in a named place. This one is more subtle than it looks, and it is usually argued badly. SharePoint Online does make data residency commitments: for a tenant provisioned in one of the countries Microsoft lists, site content and the files stored within it are held at rest in that geography (Product Terms data residency, checked on 4 August 2026). So "the data must stay in this country" is not automatically a blocker. Two things turn it into one. The first is that a tenant's default geography is fixed at creation: Microsoft states that once a tenant is created, it "can't be changed" (overview and definitions). The second is that spanning more than one geography needs the Multi-Geo add-on, which is licensed separately and carries conditions, including that purchased units exceed five per cent of the eligible licences in the tenant (data residency for SharePoint and OneDrive). A requirement to keep data on your own premises, rather than in a named country, is a different matter and does remove SharePoint Online outright.

A regulatory or contractual prohibition on the platform itself. Some obligations are not about where the bytes are. They are about who operates the service, who a court can compel to produce it, and what the organisation has signed. These are not technical questions and you will not resolve them in a technical meeting. Find out early who owns the answer, because a project that reaches the pilot before discovering it is the wrong shape does not recover the time.

A dependency with no supported equivalent. A third-party product, an integration, or an authentication method with no supported path at a destination is a hard constraint until somebody produces the path. The honest version of this sentence matters: it is a constraint until proved otherwise, not for ever, and the proof is usually a vendor's roadmap or its absence.

Soft constraints: the facts that only change the price

Everything else that people call a blocker is really a cost.

Workflows, in quantity. Numbers here are effort, not eligibility. What makes them expensive is that the rebuild is per workflow and rarely automatable. Chapter 2 asked you to split them by whether they have run recently, and that split is what turns a frightening total into a real one.

Forms. The same shape of problem: each one is small, and there are more of them than anyone remembers.

Many customisations that are not full-trust. Scripts, client-side extensions and page-level work generally have a path, and the path costs time.

Complex authentication. More than one provider on the same web application, or an unusual identity chain, does not usually eliminate a destination. It moves work forward in the plan and puts it on the critical path, which is a different kind of dangerous.

Numerous integrations. Each is a conversation with a system owner who has their own release schedule. That is a calendar problem, and calendars are the thing that most often makes a migration late.

The asymmetry between the two is the whole chapter, and it is easier to see than to read.

Figure 3.1. Hard constraints close a road. Soft constraints price one.

The table below is the one to keep. It is deliberately written in words, because the point is the weight and not a tick.

Common mistake

Choosing the destination because another organisation did the same.

It is the most reasonable-sounding argument in the room, and it is the one with the least information in it. A company of similar size, in the same sector, on the same version, that moved to SharePoint Online last year, tells you nothing about your estate. They did not have your two full-trust solutions, or they had them and paid to rewrite them, or they had them and quietly left that content behind and nobody outside the project knows.

The comparison is not useless. It is useful for the parts of the work that are genuinely common: how long the communication took, what surprised them, what they would do differently. Ask for those. What it cannot give you is your constraints, and constraints are the only input to this decision.

Constraints change, and so does the answer

A destination is chosen on a day, with the constraints known that day. Both halves of that sentence matter.

You can remove a hard constraint. The full-trust solution that eliminates SharePoint Online can be rewritten, and once it is, the option comes back. You can revisit the requirement that data stay on your own premises by re-reading the obligation behind it, and sometimes that obligation turns out to be a policy predating the current product terms rather than a law. A dependency with no supported path can acquire one when a vendor ships.

This is not an argument for delay. It is an argument for writing down why each option was eliminated, next to the option, on the day. A decision recorded as "SharePoint Online: not possible" is worthless in eighteen months. A decision recorded as "SharePoint Online: eliminated by the two full-trust solutions activated on the finance sites, quoted at N days to rebuild, not funded this year" can be reopened by anyone who later finds the funding, and reopened without redoing the work.

We recommend keeping that record as part of the project, not as a slide. It is the document that stops the same debate happening every twelve months.

Out of scope

Which destination to choose. That is chapter 4, and it needs this chapter to have been done first.

How to migrate, and with what. Tooling is chapter 29, and chapter 1 explains why it comes that late.

Licensing and cost. Both move faster than a book can, and quoting them here would age this page badly. What belongs here is that cost is a soft constraint in almost every case, and the rare occasion it is hard is when the licence for a required capability is not available to the organisation at all.

Whether some of this content should move at all. Content that nobody has opened in three years is not a destination problem. It is volume that should not be in the question, and removing it before you choose changes the estate you are choosing for.

Before you continue

• You can list your hard constraints, and each one names the fact behind it
• You can list your soft constraints, and you know they are costs rather than blockers
• For each destination you have eliminated, you wrote down why, on paper, with the date
• You know which facts are still unknown, and you are treating them as unknown rather than as absent
• You know who owns the decision, and it is not you unless you were told it is
• Nothing on your constraint list came from what another organisation did

The SharePoint Compass applies these principles as a questionnaire and returns a destination in about two minutes. It does not invent them, and it says plainly which of your facts it cannot see. This chapter is the reasoning behind it, so that you can disagree with the answer for a stated reason.