A small hosting business is bought for its recurring revenue and discounted for how much of it depends on the person selling. Both halves are improvable, and both take months.
The starting figure
Monthly recurring revenue, annualised. Hosting is valued on what continues rather than on one-off work, so migrations, development and consultancy are usually excluded or valued separately.
The multiple applied to that figure varies widely, and what moves it is not the size of the business but its transferability.
What raises it
Low churn. The single strongest signal. Customers who have stayed for years demonstrate that the revenue is durable instead of a snapshot. Have the numbers ready by year.
Documented systems. Written procedures for provisioning, support and billing mean the operation does not live in one person's memory. Reducing support tickets with documentation explains building that, and the same documents are what a buyer is paying for.
Written agreements. Each customer on stated terms with a stated price. Without them, what is being sold is a list of people who currently pay. For the document, see what to include in your hosting terms.
Automated billing and provisioning. A buyer inherits whatever labour is required, and manual work is priced as a cost. Integrating billing and automation has the detail.
What lowers it
Concentration. If three customers are most of the revenue, losing one changes the business. Buyers discount heavily for this, and it is difficult to fix quickly.
Support that depends on you personally. Customers who deal with you by name, expect replies at any hour, and receive help outside what they pay for.
That relationship is real and it is not transferable. Every hour of it is a cost the buyer inherits without the goodwill. What support to include and what to charge for goes over drawing the boundary, which is worth doing well before a sale.
Underpricing. Customers on prices set years ago will need raising, and the buyer assumes some will leave when it happens. Correcting pricing yourself, in advance, converts that discount into revenue. Pricing and packaging plans has the detail.
Prepare the record
A buyer will ask for revenue by month for two or three years, the customer list with start dates and prices, churn by year, support volume, and what infrastructure the business runs on and what it costs.
Assemble it before approaching anyone. Requests answered slowly and inconsistently reduce confidence more than the numbers themselves do.
What is actually being transferred
Be clear about it, because it is less obvious than in most businesses.
The customer relationships and their billing. The domains, if you hold them, and check who the registrant is, because a domain registered in your name for a customer is theirs rather than yours to sell. The accounts themselves, which usually means migrating them or transferring the reseller account.
Where the customers' domains are registered elsewhere, the transfer is simpler and the relationship is thinner. Moving a domain between registrar accounts deals with the mechanics if they do move.
Telling the customers
This is where value is most often destroyed after the price is agreed.
Customers who learn about a change of ownership from an invoice with an unfamiliar name will leave. The announcement should come from you, before the change, saying who the buyer is, what stays the same, and what the customer needs to do, usually nothing.
An introduction from a trusted supplier carries weight that a message from a stranger does not, and it is the last useful thing you can do for the value being transferred.
Telling clients about maintenance and outages deals with the same principle in a smaller situation: the message people remember is the one that arrived before they noticed anything.
Expect a transition period
Most agreements include a handover of some weeks, in which you answer questions and introduce customers.
Price that time honestly rather than treating it as free. It is real work, and a handover that is rushed produces exactly the churn the valuation was protecting against.
Establish the starting point before doing anything
Reputation work is judged by change, and change needs a baseline that is recorded rather than remembered.
dig example.com TXT +short | grep -i spf dig _dmarc.example.com TXT +short exim -bp | wc -l
Record what the records say, what the queue looks like and roughly what proportion of mail is being accepted, on the day you start.
Without that, every later assessment is an impression. With it, the question of whether the situation is improving has an answer that does not depend on anybody's mood that week.
The list is usually the cause
Sending reputation is largely a function of who you send to, and the fastest improvement is usually removing addresses rather than changing configuration.
grep -oiE '5\.[0-9]\.[0-9]' /var/log/exim_mainlog 2>/dev/null | sort | uniq -c | sort -rn | head grep -ci 'user unknown\|no such user' /var/log/exim_mainlog 2>/dev/null
Permanent refusals mean the address does not exist, and continuing to send to it is the single strongest signal that a list is not maintained.
Remove them on the first refusal rather than retrying. A list that generates a low proportion of these is treated very differently from one that generates many, whatever the content of the messages.
Recovery is slower than damage
A reputation lost in a day is not regained in a day, and expecting otherwise leads to changes made too quickly to evaluate.
Change one thing, then wait long enough to see the effect, which is usually a week rather than an afternoon. Changing several things at once means the improvement cannot be attributed and the harmful change is not identified.
Where sending has been suspended or blocked, the route back is through the receiving system's own process rather than through configuration. Requesting that before the underlying cause is fixed produces a refusal and a worse position than waiting. Warming up a new sending domain covers building it in the first place.