Summary

  • Elias Ward's economic judgment is that DataHarbour can be a useful regional colocation, dedicated-server and backup venue only if occupied racks and contracted workloads stay well ahead of the fixed plant, support and replacement-capital burden. The evidence does not support treating the business as a scaled infrastructure compounder.
  • Public material shows a Voronezh-centred operation marketed under the DataHarbour brand, with the related DataPort legal identity appearing on the commercial site and Russian business records. The same public record cluster links OGRN 1117746962420, INN 7714858076, the DataHarbour domain, the Voronezh address set and RIPE routing records.
  • The strongest operating evidence is practical rather than promotional: published prices for 1U colocation, full racks, dedicated servers and storage; claims of Tier III-like design, two independent power inputs, UPS and diesel redundancy; 19 STULZ precision cooling units; named carrier options; and autonomous-system records for AS199427.
  • The central uncertainty is capacity. One set of public pages and directories describes up to 212 cabinets and a larger machine-hall footprint; another current-looking home page describes 126 square metres and 39 telecom cabinets at a Vitruka address. That difference changes every utilisation conclusion.
  • The visible financial signal from public business databases is weak for a capital-heavy data-centre story: reported 2025 revenue of 24.623 million roubles, net loss of 7.038 million roubles and negative equity of 73.451 million roubles for DataPort. Those figures need primary-file verification, but they are too material to ignore.
  • The decisive facts that would change the judgment are audited revenue split by colocation, dedicated server, VPS, backup and power pass-through; current cabinet utilisation; contracted power load; customer concentration; churn; capital-expenditure backlog; debt or lease obligations; and evidence of stable demand outside low-end hosting.

Start with one occupied rack

The useful way to read DataHarbour is not to start with a data-centre label. Start with one occupied rack, one rented dedicated server, or one contracted backup workload. A customer either pays enough for space, power, cooling, connectivity, support, physical security, spares and eventual hardware replacement, or the data-centre asset becomes a costly room with impressive engineering nouns. DataHarbour publishes enough pricing detail to make that test possible, even though it does not publish enough utilisation, cost or customer data to close the model.

The company's own rack page lists two full-rack offers: an all-inclusive rack at 80,000 roubles per month and an "optimal" rack at 29,000 roubles per month, with consumed electricity shown separately. The same page says the rack is a 42U cabinet, gives physical dimensions, says power is reserved on A and B feeds, says the nominal maximum is constrained for safety, and lists 100 Gbit/s or more of aggregate channel capacity. A separate colocation page gives a 1U, 300-watt placement price of 2,530 roubles per month, with 690 roubles for each additional 100 watts and 805 roubles per month for an additional reserved port.

These are not abstract marketing claims; they define the revenue side of the unit. They also expose the squeeze.

At a full 5 kW included load, an 80,000 rouble all-inclusive rack covers roughly 3,653 kWh of IT energy in an average month before cooling, UPS losses, lighting, network equipment, hands-on support, security, property overhead, billing, tax and capital recovery. That is about 21.9 roubles of monthly revenue per included IT kWh. The "optimal" rack shifts more power risk to the customer: 29,000 roubles of base rack revenue plus a published electricity line of 12 roubles per kWh.

At 1 kW continuous load, the electricity portion alone is roughly 8,766 roubles per month, before the rack fee; at 5 kW, the electricity line is roughly 43,834 roubles. The calculation is only a stress test, because DataHarbour does not publish actual load factor, power-purchase cost or PUE. Still, it shows the economic boundary: DataHarbour is viable when paid utilisation fills the rack and when power is priced as a pass-through or embedded with enough margin. It is fragile when customers buy space but not load, or buy load at prices that do not recover cooling and replacement capital.

That is why the visible demand mix matters. DataHarbour sells colocation, full racks, dedicated servers, VPS/VDS products, backup storage, a reserve-data-centre service, Windows, 1C and game-server options, and even mining-hosting pages. The service catalogue is broad for a small operator. Breadth can help fill capacity: a regional customer may not need a full cabinet but may need one 1U server, a rented machine, offsite backup or a short-term migration. Breadth can also dilute focus: every old dedicated-server platform, low-priced VPS plan and special hosting use case requires support attention, spares discipline and billing collection.

The question is not whether these products exist. The question is whether they produce enough occupied, recurring, paid work to keep the asset ahead of its fixed costs.

Identity and control boundary

The identity evidence requires care. The directory entity is Limited Liability Company "DataHarbour". RIPE-derived autonomous-system records for AS199427 use the same English organisation name and identify Russia as the country. Those routing records also show the DataHarbour maintainer, the DataHarbour AS name, an organisation object, the registration number 1117746962420, Voronezh address data and DataHarbour contact channels. That is the strongest reason to treat DataHarbour as an operating network identity rather than merely a website label.

At the same time, DataHarbour's own commercial site repeatedly says the data centre is operated by ООО "ДатаПорт", and the DataPort site's documents page lists ООО "ДатаПорт" with INN 7714858076, OGRN 1117746962420, the DataHarbour website and DataHarbour contact email. Russian company-profile sources, including RBC Companies, identify ООО "ДатаПорт" under the same OGRN and INN, with a Voronezh legal address, general director Kirill Kornev, a 20,000 rouble charter capital line, 10 employees and a sole founder entry for Lyudmila Romanova.

DataCenterMap describes DataHarbour as a subsidiary or brand connected to DataPort, while AllDC lists the operator as ООО "ДатаПорт" and the facility as DataHarbour.

The prudent reading is that public sources tie the DataHarbour network and facility brand to the DataPort Russian legal entity, but they do not perfectly explain the English legal-name translation used in the RIPE object. That boundary matters for risk. If a customer is buying a rack, the contract counterparty, property rights, power agreement, carrier cross-connects, equipment insurance and legal collection rights likely sit with DataPort rather than with a separate English-name shell called DataHarbour. If an Internet operator is evaluating AS199427, the routing identity is DataHarbour.

If an investor or creditor is evaluating solvency, the useful public records are the DataPort records. The article therefore treats the operating object as DataHarbour while keeping the legal and financial evidence tied to the DataPort identifiers when the source does so.

There is another boundary: DataHarbour is not, on public evidence, a hyperscale cloud. It is a regional data-centre, hosting and network operator selling placement, rented hardware, virtual servers and related services. Its value proposition is local control, Russian-hosted data, support, backup and connectivity, not instant global scale. The company's own pages frame the appeal around avoiding the cost of a customer's own server room, getting redundant power and cooling, using multiple carriers, receiving round-the-clock support and keeping equipment in a controlled facility. Those are legitimate needs.

They also put DataHarbour in a competitive lane where trust, availability, power discipline and renewal economics matter more than slogans.

What the infrastructure evidence proves, and what it does not

DataHarbour's infrastructure claims are unusually concrete for a small regional provider, but they are not equivalent to a certified engineering audit. The home page says the DataHarbour data centre corresponds to Tier III reliability characteristics but notes that Uptime Institute certification was not conducted. It lists uninterruptible and guaranteed power supply, precision cooling, smoke and gas fire-protection systems, physical access control, video surveillance, round-the-clock security, monitoring and support, and an annual availability indicator of 99.98%.

The power page adds two independent first-category power inputs with total power of 4.4 MW, four Riello UPS units in N+1 configuration and three Wilson diesel generators with a total rating of 2,700 kVA. The cooling page gives 19 STULZ precision air-conditioning units in N+2 configuration and a target of plus 20 degrees Celsius, plus or minus 2 degrees, in cold corridors. The fire-protection page names Novec 1230 gas suppression, BOLID early smoke detection and smoke-removal systems. The security page lists guarded premises, card-based physical access segmentation, video monitoring and guard or duty-shift control.

These details prove that the facility marketing is anchored in specific equipment types and data-centre operating disciplines. They do not prove current maintenance state, fuel reserves, tested generator runtime, UPS battery age, chiller redundancy under peak summer conditions, annual incident history or SLA payouts. They also do not prove that the advertised design is available at each sales location. The Voronezh pages carry the strongest technical detail. The Moscow, Kursk and Belgorod pages look more like local sales or service-location pages and are less technical.

DataCenterMap lists four DataHarbour locations: Voronezh, Moscow, Kursk and Belgorod. The DataHarbour sitemap likewise exposes contact pages for those four locations. The public evidence supports saying DataHarbour markets four locations, but the deeper facility evidence remains centred on the Voronezh asset.

Capacity is the biggest unresolved engineering variable. The company's home page says the facility is at Vitruka 12, building 3, with a 126 square metre server room and 39 telecom cabinets. The rack page says the company can rent from 212 cabinets. The colocation page says machine halls can place up to 212 cabinets. A 2015 company press page and AllDC profile also describe a much larger facility footprint, including 1,000 square metres of total area, 567 square metres of raised floor and 212 racks. The Voronezh address page, however, says the data centre is at Zemlyachki 1. RBC Companies lists a Vitruka legal address.

These records may reflect relocation, expansion, old copy, separate legal and operational premises, or stale third-party listings. Public material does not resolve it. A serious customer or lender would need a current facility tour, floor plan, power single-line evidence, occupancy schedule and ownership or lease documents before using either 39 cabinets or 212 cabinets as the denominator.

The contradiction does not make the company imaginary. It makes utilisation analysis dangerous. If the real operating base is 39 cabinets, reported revenue in the mid-20-million-rouble range may be compatible with a meaningful occupied base when dedicated servers, VPS and storage are included. If the real built capacity is closer to 212 cabinets, the same revenue level looks thin against fixed plant and replacement requirements. The difference is the difference between a small, possibly busy regional room and an underabsorbed data-centre shell.

Connectivity is a real asset, but it is small

For a data-centre customer, power keeps the servers alive, but connectivity determines whether the facility is an operating node or just a protected electrical room. DataHarbour's provider page says the data centre is carrier independent. It says clients can use any communications provider, that multiple backbone telecom channels of at least 10 Gbit/s each are expected or available, that channels come from several independent providers on different routes, and that customers can connect at 100 Mbit/s, 1 Gbit/s or 10 Gbit/s. The telecommunications page adds potential fibre rental to Moscow's MMTS-9 and MMTS-10 interconnection sites.

The provider list includes TTK, Informsvyaz-Chernozemye, Kvant-Telecom, Rostelecom, Beeline, MSK-IX, Voronezh-Telecom and MTS. The rack page advertises aggregate channel capacity from 100 Gbit/s and a minimum network availability of 99%.

Routing databases support a narrower but real Internet footprint. AS199427 is listed as DataHarbour-AS. IPIP's RIPE-derived page shows AS199427, the organisation name Limited Liability Company "DataHarbour", a route set reference and import/export relationships with AS24923, AS3216 and AS9049. AbuseIPDB reports one IPv4 block and no IPv6 blocks. 2ip and IPIP records identify the 185.40.76.0/22 block, which is 1,024 IPv4 addresses. Cloudflare Radar has a routing page for AS199427, identifying the AS name and country and providing current routing-statistics views.

These sources are not customer references, but they show that DataHarbour is visible in public BGP data, not only in facility advertising.

The limitation is scale. A single /22 IPv4 allocation and no visible IPv6 prefix in the third-party summaries is enough for a hosting and regional colocation provider, but it is not a large network moat. IPv4 scarcity may have some value, and included IPv4 addresses matter to dedicated-server and colocation pricing. Yet the AS footprint does not suggest an operator with broad national transit leverage. The company likely buys and aggregates upstream connectivity rather than controlling a deep, independently monetisable carrier network.

That is consistent with the commercial pitch: provider-independent facility, several carrier options, reserved ports, cross-connect work and optional fibre. It is not evidence of network dominance.

The connectivity evidence also sharpens the unit-economics question. If DataHarbour sells low-cost VPS and dedicated machines, it must absorb or pass through carrier, DDoS, IP-address and routing operations costs. Dedicated-server plans on the official page range from 3,520 roubles per month for an Intel Core i3 platform to more than 26,000 roubles per month for higher-memory Xeon configurations, with one server line priced by negotiation. Those server prices are attractive to a buyer who needs Russian hosting, but older hardware families imply a replacement-capital problem.

Customers will not indefinitely pay a premium for aging platforms if cloud alternatives, newer dedicated hosts or competing regional providers offer better performance per rouble. The network layer can support DataHarbour's offer, but it cannot rescue hardware economics if utilisation or renewal pricing is weak.

Customer revenue must be separated from pass-through revenue

The economic question asks whether hosting or data-centre revenue can sustain power, cooling, connectivity, support and periodic equipment replacement at realistic utilisation. That requires separating customer revenue from power and carrier pass-through. DataHarbour's public tariffs make clear why. The 80,000 rouble rack looks like a high monthly ticket, but part of that ticket is power, part is cooling, part is network access, part is physical security, part is support availability, and only the remainder contributes to fixed-cost and capital recovery. The 29,000 rouble rack is more transparent because electricity is separate.

The 1U tariff is smaller but more granular: 2,530 roubles per month for 300 watts, then 690 roubles per extra 100 watts.

From a customer perspective, the 1U tariff is simple. A small company that owns one server can place it in a professionally managed room rather than maintain a closet, UPS, cooling, firewall, camera and emergency access process. From DataHarbour's perspective, that same 1U customer is operationally demanding. The server occupies rack space, consumes power, contributes heat, requires remote-hands potential, receives IP addresses and port access, and creates billing and support obligations. If many 1U customers are low power and sticky, they can fill cabinets profitably.

If they churn, request frequent work or consume incremental power at thin margins, they can become costly.

The full rack is more attractive if it is truly occupied. One sold 42U cabinet can absorb support overhead better than many one-off units. But the power-risk allocation matters. A fully loaded 5 kW all-inclusive rack at 80,000 roubles per month is a different business from a lightly loaded rack at the same price. If power use is low, the provider captures more margin but the customer may eventually downgrade. If power use is high, the provider's energy and cooling burden rises. The "optimal" rack partly solves that by making electricity visible, but it lowers the base monthly fee to 29,000 roubles.

DataHarbour's task is to mix those tariffs so it is not giving away power in the high-load case or sitting on empty cabinet shells in the low-load case.

The official backup-storage tariffs are low-ticket but potentially sticky: plans range from 345 roubles per month for 100 GB to 13,110 roubles for 10 TB, with a 100 Mbit/s unlimited-channel line and standard protocols such as FTP, FTPS, SCP, CIFS, HTTPS and WebDAV. Backup storage can smooth utilisation because it does not require each customer to rent a full cabinet. But storage economics depend on disk replacement, replication, backup integrity, support and restore bandwidth. Without a disclosed storage architecture, retention policy, erasure-coding plan or churn data, backup cannot be assumed to subsidise the data-centre plant.

It is an add-on that may fill demand, not proof of margin.

The reserve-data-centre page is strategically more interesting. It pitches Voronezh as a backup site about 500 km from Moscow and bundles equipment placement, virtual compute, guaranteed-bandwidth Internet channels, L2 virtual dedicated channels, fibre, backup, DDoS protection, data synchronisation, round-the-clock support and office or warehouse rental. That is a higher-value enterprise proposition than low-end hosting. If DataHarbour wins real reserve-site contracts, it can monetise the regional location and redundancy story. The public source, however, is a product page, not a customer list.

It supports the existence of an offer, not contract depth.

Public financial signals are thin for the stated capacity

DataHarbour and DataPort do not publish audited management accounts on their site. The most useful public financial snapshot found in open business databases is RBC Companies' profile for ООО "ДатаПорт". RBC reports 2025 revenue of 24.623 million roubles, 2025 net loss of 7.038 million roubles, total assets of 16.300 million roubles and negative equity of 73.451 million roubles in its abbreviated page, with the full profile also noting 10 employees.

Because this is a third-party presentation of Russian company information, it should be checked against official Federal Tax Service accounting records before use in a financing decision. But as a market signal, it is highly relevant.

One simple comparison shows why. At 80,000 roubles per month, a fully billed all-inclusive rack produces 960,000 roubles a year. Reported 2025 revenue of 24.623 million roubles is equal to about 25.6 such rack-years. That does not mean DataHarbour had 25.6 full racks; revenue also comes from dedicated servers, VPS, backup, setup, support, power pass-through and possibly other services. It does show the order of magnitude. If the real capacity denominator is 39 cabinets, 25.6 all-in rack equivalents is not absurd. If the real denominator is 212 cabinets, it is low.

Using the lower 29,000 rouble rack base, 24.623 million roubles equals about 70.8 rack-years before power pass-through. Again, that is not an occupancy measure, but it shows how sensitive the interpretation is to tariff mix.

The loss and negative-equity signals also fit the replacement-capital concern. A data centre must replace disks, servers, switches, UPS batteries, cooling components, fire-system consumables, PDUs, monitoring equipment and security systems. Some of that can be deferred. Too much deferral becomes customer risk. If the company is losing money and has negative equity, the burden shifts to collections discipline, owner support, creditor patience, lease or property status, and the ability to price renewals. A small operator can survive with negative accounting equity if it owns hard assets, has stable cash collections and low debt service.

Public sources do not provide that reassurance. They show enough to make the issue central and not enough to dismiss it.

DataHarbour's own cost story is partly favourable. The site says the premises are owned by the company. If current and true for the operating facility, ownership reduces landlord-renewal risk and may improve collateral. The company also says engineering systems are serviced under contracts with specialised organisations, which can make operations more reliable but adds cash cost. The power page shows serious standby infrastructure, but standby infrastructure is not free to maintain. The dedicated-server page uses HP, Supermicro and Intel references and offers replacement in case of equipment failure.

That promise is valuable only if spare-parts and refresh economics are budgeted.

The result is a guarded judgment. DataHarbour may be deliberately small and profitable at the cash level, with public accounting distorted by depreciation, historical losses or real-estate structure. Or it may be underutilised and living off aging equipment while competing on price. The public record cannot choose between those scenarios. It does justify demanding utilisation and renewal evidence before treating the company as financially robust.

Customer concentration and demand are not visible enough

Customer concentration is the weak spot in the public evidence. The company pages describe target customers: local businesses, government sector, utilities, IT companies, 1C users, gaming services, web projects, backup customers and organisations needing reserve infrastructure. They do not list current major customers. The press pages from 2014 and 2015 show regional-government attention and quote management on the value of a Voronezh data centre, including the idea that local government entities could save money versus maintaining internal IT departments.

The import-substitution press item says the centre was not seeing sufficient demand in the region at that time, particularly from government institutions, and that outdated budget practices made adoption harder. That historical note is important because it comes from the company's own press section and undercuts a simple growth story.

Court records provide fragments, not a customer book. SudAct records show ООО "ДатаПорт" appearing in arbitration matters, including a 2018 decision in which DataPort recovered unjust enrichment and interest from the Voronezh Medical Information and Analytical Center. Other litigation references include PromInvest-related disputes and a 2026 appeal in a damages case. These records show the company has had legal disputes and at least one public-institution counterparty in a paid-services context. They do not prove current recurring revenue, concentration, credit quality or customer satisfaction.

They do, however, remind the reader that collection risk is real in regional infrastructure services, especially when public-sector adoption is part of the pitch.

Unofficial market signals are mixed and should be handled with restraint. DataCenterMap lists DataHarbour as an operator with four data centres, and AllDC provides a detailed facility profile. Those directories support market visibility. Hosting101 has a DataHarbour page with a small number of user signals, including one sharply negative former-customer review and a low average score based on very limited participation. Because the sample is tiny, it cannot establish systemic service quality. But for a data-centre operator, even weak complaints about support, communication or equipment moves are relevant watch items.

The right conclusion is not that the complaint is representative. The right conclusion is that customers considering colocation should ask for change-management procedures, maintenance notices, SLA history, escalation contacts and recent references.

Demand also faces substitution. A small business can colocate a server with DataHarbour, rent a dedicated machine from DataHarbour, rent a VPS from DataHarbour, use a larger Russian cloud, use a managed hosting provider, or keep equipment on premises. Yandex Cloud publishes pay-as-you-go compute pricing, reserved-resource discounts for compute and RAM, per-second billing, storage and outgoing-traffic charging, and a 100 GB monthly outgoing-traffic allowance.

Selectel publishes cloud and VDS pay-as-you-go models, included outbound traffic for cloud servers, DDoS and firewall features in cloud-server packages, and broad public infrastructure pricing. These larger providers change buyer expectations: customers compare not only raw monthly price, but provisioning speed, API, snapshots, managed services, backup, network included allowances, security features and scaling.

DataHarbour's defence is locality, physical access, regional support, Russian data placement, possible reserve-site distance from Moscow and bundled hands-on help. That can be enough for customers with owned hardware, local compliance, 1C workloads, conservative IT departments or low-latency regional needs. It is not enough for customers whose workloads can move easily to a cloud account and scale down when not in use. DataHarbour therefore needs sticky customers with reasons to occupy physical or semi-dedicated capacity, not just bargain hunters.

Competition, replacement cycles and sanctions risk

The competitor set is not only local data centres. It includes the customer's own server room, national colocation operators, dedicated-server providers, cloud platforms and managed-service firms. AllDC's profile places DataHarbour alongside Russian data-centre names such as Stack, SafeData, DataLine, CROC and LinxTelecom in a broad comparison. DataHarbour's own copy makes similar comparisons. That comparison may help marketing, but it also sets a high bar.

Larger operators have more procurement leverage, broader carrier density, more customers to absorb 24/7 staffing, deeper spare pools and stronger ability to finance periodic upgrades. DataHarbour must compensate with price, local access, flexibility and responsiveness.

Replacement cycles are the hard part of a dedicated-server portfolio. The official dedicated-server page still lists configurations based on Intel Core i3-6300, Core i7-6700, Core i7-4770, Xeon E3-1220, Xeon E3-1270, Xeon E5-1650, Xeon E5-2609 and Xeon E5-2620 families. Those machines may be perfectly adequate for many legacy workloads, 1C environments, small web projects, storage-heavy services or customers who value low prices. They also imply aging silicon relative to current cloud and dedicated-server offers. Older hardware can be profitable when already depreciated and occupied.

It becomes a trap when customers demand performance upgrades before the provider has generated replacement cash.

Suppliers add another layer. DataHarbour names Riello UPS, Wilson diesel generators, Schneider-Electric metering, STULZ cooling, Novec 1230 fire suppression, BOLID detection and HP, Supermicro and Intel server hardware. This equipment base is credible. It also has maintenance and import-exposure implications in Russia. Since 2022, sanctions and supply-chain fragmentation have made Western-origin equipment support, spares and licensing harder for many Russian infrastructure operators. Public DataHarbour sources do not disclose spare inventory, alternative supplier arrangements, warranty status or upgrade plans.

That uncertainty is not a reason to assume failure. It is a reason to require evidence before relying on long service commitments at fixed prices.

Regulatory and geopolitical risk is broader than sanctions. Russian data-localisation rules can support local data-centre demand by encouraging domestic storage and processing. The same environment can increase compliance burden, payment friction, procurement complexity and technology substitution pressure. If public institutions or regulated businesses prefer domestic infrastructure, DataHarbour benefits only if it can satisfy procurement, security, audit and continuity expectations. If larger state-aligned or national providers consolidate demand, a regional operator may be squeezed. The public record does not show a protected franchise.

It shows a regional operator that has tried to position itself as the first Voronezh data centre, an innovation project and an import-substitution asset.

Power risk is similarly two-sided. Data centres are power businesses with servers attached. DataHarbour's published redundancy claims are strong for a small operator, but the cost of electricity, diesel testing, generator maintenance, UPS refresh and cooling increases must be recovered. The rack tariff line that separates consumed electricity is economically healthier than burying all energy risk in a flat fee. The all-inclusive rack may be easier to sell but more dangerous if high-density customers use the allowance fully.

The right pricing posture is not necessarily the highest rack price; it is a tariff structure that keeps DataHarbour indifferent between a low-load and high-load customer after all energy and cooling costs.

Three operating scenarios

The first operating scenario is the disciplined regional-colocation case. DataHarbour knows exactly which cabinets are live, meters heavy customers separately, keeps the all-inclusive rack for moderate-density workloads, uses the 1U tariff to capture small but sticky local customers, and sells backup storage as a retention product rather than a stand-alone low-margin commodity. In this version, older dedicated servers are not a weakness by themselves. They are already depreciated machines rented to customers whose applications do not require the newest CPUs.

Replacement capital is budgeted slowly but honestly: disks, fans, power supplies, access switches and UPS batteries are refreshed before failure rates become visible to customers. The company remains small, but its smallness is controlled.

The second scenario is the underoccupied-asset case. The public 212-cabinet claim is close to the real asset denominator, but paid load is far lower. Management then has an incentive to accept almost any workload that produces cash, including low-margin dedicated servers, high-support VPS users, mining-style power loads or one-off customers who bargain hard because alternatives exist. In this scenario, a broad service menu is not diversification; it is evidence of demand search. The risk is that accounting revenue rises while economic margin stays weak because every new customer consumes support, carrier, energy and hardware resources.

The company can look busy while still failing to fund replacement capital. The RBC loss and negative-equity signal would fit this scenario, although it does not prove it.

The third scenario is the capacity-transition case. DataHarbour may have moved, resized, reconfigured or split functions across sites, leaving public pages that describe different phases of the business. The Vitruka 39-cabinet description may be current for one room while the Zemlyachki and 212-cabinet materials may reflect a previous or broader operating footprint. If so, the public contradiction is less damning, but it still matters commercially.

Buyers need to know where their equipment will sit, what power architecture applies to that exact room, which carriers are actually present there, and whether the advertised rack, backup and reserve-data-centre services are delivered from the same facility or through a combination of owned space, partner sites and sales offices. A small provider can operate through such a mix, but the risk contract must match the actual topology.

These scenarios lead to different professional conclusions. In the disciplined case, the main diligence question is whether the tariff book is kept current and whether capex reserves are real. In the underoccupied case, the main diligence question is whether customers are being used to cover short-term cash needs at prices that weaken the future plant. In the transition case, the main diligence question is documentation: floor plan, access rights, power feed, carrier route, insurance, legal counterparty and service-level boundary for each location.

None of these questions can be answered from public web sources alone, but the public sources are good enough to show where the questions should land.

What would change the judgment

The bullish case is possible but unproven. In that case, DataHarbour owns or controls the key Voronezh premises, has filled a meaningful share of available cabinets, has a disciplined mix of colocation, dedicated-server, backup and reserve-site customers, passes through heavy power use, has low customer churn, maintains spare parts despite import pressure, and uses older servers because customers willingly rent them at prices that more than cover maintenance. The four-location marketing footprint would then be a sales network around a practical regional platform, not empty expansion language.

The reported accounting loss might reflect depreciation, historical liabilities or growth expenditure rather than cash distress.

The bearish case is also possible. In that case, public capacity claims overstate current paid load, the facility has too many low-ticket customers, dedicated-server hardware is aging faster than tariffs allow, backup and VPS services add support complexity without margin, customer concentration is high, legal collection risk is recurring, and replacement capital is deferred. The financial data shown by RBC would then be a warning sign, not an accounting quirk. A broad service menu would be a symptom of searching for demand rather than a sign of diversification.

The public evidence leans to caution because it shows tangible infrastructure but not enough occupied demand. The capacity contradiction is too large to ignore. The 39-cabinet figure and the 212-cabinet figure cannot both be used casually. The AS199427 footprint is real but small. The tariff book is real but tight under high power consumption. The official site gives meaningful engineering detail but no incident, utilisation or certification proof. The financial snapshot is weak. The public customer evidence is thin. The market alternatives are better capitalised.

Elias Ward's economic judgment is therefore this: DataHarbour's value is not in nominal data-centre capacity; it is in paid, supportable, power-aware occupancy. The company should be assessed as a regional infrastructure operator whose economics improve when each rack, server and backup plan is contracted, metered and renewed with replacement capital in mind. It should not be assessed as a high-confidence data-centre growth platform until it shows current cabinet count, occupied load, customer concentration, cash collections and capex reserve discipline.

For customers, the practical question is whether DataHarbour can provide reliable local hosting at a known cost. For creditors or strategic partners, the harder question is whether the business can renew equipment and engineering systems without relying on underpriced power, deferred maintenance or one-off customer wins. At present, the public record supports the first possibility more than the second.

Sources