The Cloud That Remained: Source2Cloud and the Price of Verifiable Control

Summary

• Source2Cloud B.V. is a continuing Dutch legal and operational identity, not another name for Source2Cloud Services B.V. The latter was acquired by Voys in 2024 together with the hosting operation for major-business telephony servers at three Dutch locations; the surviving company retained its own registration, public brand, RIPE resources and current activities, but no public asset schedule shows which physical infrastructure it retained.
• Its proposition combines dedicated private-cloud hosting, migration consulting, network and system administration, and VoIP. The attractive part is not simply local hardware: it is the possibility of putting design, cutover and daily operations in one accountable team. That value remains a company claim until a buyer sees the actual facilities, responsibility matrix, service levels, subcontractors and evidence of recovery.
• AS209223 is still assigned to Source2Cloud B.V., and its IPv4 allocation and route object remain registered. Yet RIPE’s current routing observation showed no announced prefixes on July 17, 2026 and last saw an originating route on April 28. Registration therefore proves a network resource and an operating option, not current internet-path autonomy.
• The decisive procurement test is a reversible migration. A credible bid should identify the contracting entity, owned and partner-controlled layers, migration artefacts, security evidence, incident responsibilities, complete price schedule and an exit rehearsal. Without those, “private”, “sovereign” and “no lock-in” remain adjectives; with them, a small provider can offer unusually direct operational control.

Begin with the suffix

In cloud procurement, the smallest line of type can carry the largest risk. The service name may be familiar, the founder may remain involved and the website may look continuous, but the contract sits with a legal person. If equipment, customer agreements or operational staff cross a corporate boundary, a buyer needs to know which side of the boundary will answer a ticket at two in the morning.

That is the right way to read Source2Cloud. The exact company examined here is Source2Cloud B.V., registered in the Netherlands under Chamber of Commerce number 60404558. A Dutch business-data page records its establishment in April 2014, its Zevenaar address and its information-technology services activity. It also estimates a workforce of two to five people. Those details are secondary registry-derived evidence rather than an audited corporate filing, but they consistently identify the assigned company. The current company entry should not be merged with any business merely because both use the Source2Cloud name.

The distinction became commercially important in January 2024. Voys announced that it had acquired Source2Cloud Services, a separate Dutch company. Voys said that Source2Cloud Services had been responsible for servers supporting a large share of its major-business telephony customers, distributed across three Dutch datacentre locations. Voys would henceforth manage that local hosting itself and integrate the acquired services. Bas Dorland, the announcement added, would continue his business activities under the Source2Cloud name and remain involved after the transfer. Voys’s transaction account repeatedly names Source2Cloud Services; it does not say that Voys bought Source2Cloud B.V.

Independent trade coverage preserved the same distinction. Computable’s January 2024 acquisition round-up says Voys bought Source2Cloud Services and brought management of the three-location hosting operation in-house. A company-data page associates Source2Cloud Services B.V. with Chamber of Commerce number 56178727 and now describes that entity as dissolved. Its separate corporate entry is not evidence about the legal status of Source2Cloud B.V.; it is evidence that the two names belonged to different legal records.

This suffix discipline changes the article’s starting point. Historical performance for the Voys telephony estate cannot simply be credited to the surviving company. Nor can assets sold in that transaction be assumed to remain available to it. At the same time, the sale did not erase Source2Cloud B.V. Its present identity has several mutually reinforcing anchors: a live service website; an active RIPE organisation record; a Dutch vocational-training recognition; and a newer automation trade name that explicitly identifies its legal owner as Source2Cloud B.V. The company that remains is real enough to assess.

The challenge is to establish what, exactly, remains under its control.

What the Voys transaction removed, and what it did not prove

The acquisition offers an unusually revealing negative image of the business. Voys described the part it wanted: servers used for major-business telephony, local datacentre hosting across three Dutch locations and the ability to manage those servers directly. It also gave an economic reason. Bringing management in-house would expand Voys’s margin and help it maintain competitive enterprise pricing. That is a concise description of why infrastructure control matters: ownership or direct operation can remove a supplier layer, change unit economics and shorten an operational chain.

The date has a wrinkle. A later Voys carbon report says that Voys bought assets from “Source2Cloud” in October 2023, while the public acquisition announcement arrived in January 2024 and names Source2Cloud Services. The most restrained interpretation is that the operational transfer or asset purchase occurred in late 2023 and was announced later. The report’s shortened name is not enough to reassign the seller to Source2Cloud B.V., particularly when the specific transaction release and independent coverage use Source2Cloud Services.

No public purchase agreement or asset schedule was located. The evidence therefore does not reveal whether every server was transferred, whether leases or colocation contracts were assigned, whether software licences moved, or whether only the Voys-serving estate was included. It does not show which employees, if any, changed sides. It does not show whether Source2Cloud B.V. had separate equipment in any of the same facilities. A purchaser should resist two equal and opposite errors: assuming the surviving company kept the old telephony platform, and assuming it was left with nothing.

What can be verified after the transaction is narrower. The RIPE organisation entity for Source2Cloud B.V. remained an active local internet registry record and was modified in May 2026. The assigned AS209223 entity still points to that exact organisation. The Dutch vocational-training portal lists Source2Cloud B.V. at Mercurion 32C-2 in Zevenaar, with Bas Dorland as the contact, and recognises it for work involving the installation and management of infrastructure, applications, user questions and service tickets. That SBB training-company record is not a service-quality certificate, but it is current institutional evidence of an operating technical workplace.

There is also evidence of a broadened business. HappyAutomate says expressly that it is a trade name of Source2Cloud B.V. in Zevenaar. It markets workflow optimisation, chatbots, Microsoft Copilot work, training and custom automation, delivered remotely. The page occasionally styles the brand as though it were a company in its own right, but its legal disclosure resolves the point: HappyAutomate is a trade name, not a substitute directory entity for this analysis.

Taken together, the post-deal picture is of a small, continuing technical company that has rebuilt or repackaged its public offer around private cloud, administration, consulting, VoIP and automation. What cannot be inferred is continuity of the old asset base or customer book. That uncertainty is not a reason to dismiss the offer. It is a reason to make chain of custody the first procurement workstream.

The product is an operating boundary, not a rack of servers

Source2Cloud’s present website presents four connected services. Its private-cloud offer promises compute hosts reserved for one customer, hardware-level isolation, configurable processor and memory resources, private or customer-supplied networks, redundant VPN or dedicated-fibre connections, hybrid links to public cloud and local support. Its network and system administration service covers monitoring, patching, firewalls, intrusion detection, VPNs, servers, backups, disaster recovery, load balancing, users and devices. Its consulting page offers assessments, network design, cloud strategy, migration, cyber-security, continuity planning and cost optimisation. The VoIP service adds cloud PBX, SIP trunks, handsets, softphones and managed support.

These are company statements, not independently observed capabilities. Even so, their combination describes a coherent customer workflow. A medium-sized organisation with ageing on-premises servers may not want a raw virtual machine catalogue. It wants someone to inventory applications, redesign the network, move workloads, administer the result, secure remote access, protect data, resolve faults and possibly replace its telephone system. The product is the transfer of operational responsibility across that sequence.

This is where a small managed provider can differ from a hyperscale cloud. A customer may speak to the people who designed the environment rather than navigate separate sales, architecture and support queues. Non-standard network requirements may be easier to discuss. Dedicated hosts can simplify performance attribution and reduce co-tenancy concerns. A local team may be able to inspect a physical dependency, coordinate a carrier and modify a firewall in one incident call.

But the same integration can concentrate risk. If one provider holds the architecture diagram, hypervisor credentials, backup configuration, firewall rules, carrier contacts and recovery knowledge, the customer may have fewer contractual suppliers but more dependence on one operational brain. “Complete control” is therefore ambiguous. Source2Cloud can mean that the customer has administrative access and a dedicated environment. A buyer may mean that it can independently observe, change and leave the environment. Those are not the same.

The public offer contains strong language: dedicated local datacentres, enterprise-grade security, service-level uptime, round-the-clock monitoring, no long commitments and, on the private-cloud page, no third parties involved in support. Its home page also claims simple pricing and says thousands of businesses rely on the company. No public customer count, achieved-availability series, facility list or downloadable service-level schedule was found to substantiate those statements. The statements are useful as items to place into a contract; they are not yet the contract.

The right procurement unit is consequently not “a private cloud”. It is a documented operating boundary. For every layer, the buyer needs to know who owns the asset, who configures it, who monitors it, who can change it, who receives an alarm, who bears the cost of failure and what is handed back on exit. Only then does a rack of dedicated hosts become an accountable service.

Mapping the claimed architecture

The company’s architecture can be reconstructed at a functional level, though not as a verified deployment diagram. At the bottom is a facility layer: power, cooling, physical security, fire suppression, carrier entry, remote hands and cross-connects. Above it sits physical compute and storage. Source2Cloud says dedicated private-cloud hosts are reserved for an individual customer. It does not identify the server vendors, storage topology, spare-parts policy, host density or whether storage is physically dedicated as well as compute.

The virtualisation layer is also unspecified on the product pages. A company-controlled LinkedIn profile lists experience with VMware, Citrix, Nutanix, Proxmox, XCP-ng, Xen Orchestra and Microsoft cloud tooling. That is evidence of the company’s stated skill range, not proof that any one stack underpins the current service. The distinction matters. A three-node Proxmox cluster with replicated storage presents different failure, licensing and export characteristics from a VMware estate backed by a shared array, a Nutanix cluster or an XCP-ng pool. A bidder should name the proposed stack and version, not offer a menu of familiar logos.

The network layer appears designed for customisation. The private-cloud page offers public networking, dedicated networks, customer-supplied networks, VPNs and fibre. This could support a useful migration pattern: extend an existing address plan into the hosted environment, replicate services, change routes at cutover and retain a path back during rollback. It could also create hidden dependencies on a specific colocation cross-connect, firewall appliance, upstream carrier or managed configuration. “Bring your own network” should mean more than accepting the customer’s IP range.

It should identify route control, filtering, address ownership, DDoS handling, out-of-band access and the fate of configuration on exit.

Above the infrastructure sit operating systems, identity, applications and data. Source2Cloud’s administration page implies that its responsibility can extend through servers, accounts, devices and backup. The boundary will vary by customer. In one contract the provider may patch only the hypervisor; in another it may administer Windows servers and Microsoft 365 identities; in a third it may support an application without owning its code. A service description should use a responsibility matrix that names each control, not a sentence saying the environment is “fully managed”.

The final layer is evidence. Monitoring data, change records, backup reports, vulnerability findings and incident timelines are part of the architecture because they make control visible. A customer cannot verify a recovery promise from a green dashboard alone. It needs to see which components were tested, how long restoration took, whether application consistency was checked and whether the test relied on the same identity or network system whose failure it was supposed to survive.

Source2Cloud’s claimed stack is plausible for a small managed-cloud operator. The public material supports a design hypothesis, not a deployed topology. That is a useful distinction in a competitive process: invite the company to turn each claim into a named component, owner, dependency and acceptance test. The completeness of that response may be more informative than the brand of server.

AS209223: a registered option, not a live route

Source2Cloud has an unusually inspectable network marker. RIPE assigned AS209223 to Source2Cloud B.V. in March 2019. The exact legal name, Dutch address and maintenance references align with the company. RIPE also records an IPv4 allocation from 2.57.12.0 to 2.57.15.255 under the Source2Cloud organisation. The allocation entity was updated in 2025. These are primary registry facts: the company has been allocated internet number resources and retains the relevant registry entities.

They do not establish that Source2Cloud is currently originating traffic. RIPE’s announced-prefixes endpoint returned an empty set in the frozen July 17, 2026 observation. Its routing-status record showed no IPv4 or IPv6 space visible to its collectors. RIPE last observed AS209223 originating 2.57.12.0/24 on April 28, 2026. At the article date, none of 326 reporting IPv4 peers in that observation saw a route from the system.

There is still an Internet Routing Registry route object for 2.57.12.0/24 with AS209223 as origin, created on July 5. The RIPE route-object search shows administrative intent or permission to originate the route; it is not a BGP sighting. A route-origin authorisation check also reports a valid authorisation. That is a positive routing-security control for the specified origin and prefix. It still does not make a withdrawn route visible.

Commercial aggregators illustrate why timestamp and method matter. IPinfo currently labels AS209223 inactive with no prefixes, while Hurricane Electric distinguishes one historically originated prefix from zero currently announced prefixes. By contrast, IPIP’s AS page shows one IPv4 prefix and a previous upstream relationship. These pages are not necessarily irreconcilable: they can use different collectors, refresh cycles and definitions of “active”. For a current claim, the dated RIPE routing observation deserves greater weight than an undated aggregate.

The restrained conclusion is important. Source2Cloud B.V. possesses a registered autonomous-system identity and associated address resources. It had a visible route until late April 2026 and maintains a current route object and valid origin authorisation. It was not visibly originating prefixes in the frozen observation. This could be a temporary withdrawal, a redesign, a backup configuration or a longer operational change. The public evidence does not say which.

For a customer, the question is not whether owning an ASN sounds impressive. It is whether the proposed service will use it. A tender should request the production prefixes, upstreams, route policy, diverse paths, origin authorisations, DDoS procedure and recent reachability evidence for the actual customer environment. If the design instead uses a datacentre or partner network, that can be perfectly sound. It should simply be priced and governed as partner capacity rather than presented as independent Source2Cloud routing.

The partner layer hiding inside “local”

“Local cloud” can describe jurisdiction, support, facility location, company ownership or network path. Those dimensions frequently diverge. A Dutch company may operate equipment in a Dutch facility while depending on another Dutch carrier, a US content-delivery network, Microsoft identity services and a remote software platform. Locality can be valuable, but only when the buyer specifies which dimension matters.

Source2Cloud’s public endpoints expose several such layers. The main website was delivered through Cloudflare in the frozen observation, and its mail configuration used Microsoft’s hosted service. The site’s conversational widget loaded through n8n’s cloud domain. These are ordinary modern dependencies, not evidence of a defective private-cloud service. They do show why an absolute phrase such as “no third parties involved” requires a defined scope. It may refer to first-line support, while the service chain still contains facility, connectivity, software and web-platform suppliers.

The telephony links are more revealing. Source2Cloud’s VoIP administration link resolved during research to an address in a prefix originated by AS201791, identified by RIPE data as Voys Devhouse Spindle B.V.; the relevant prefix observation did not place it in AS209223. The VoIP knowledge link pointed to a VoIPGRID wiki and an address routed by AS39591, Previder; its prefix observation likewise showed partner infrastructure. DNS and routing can change, and a front-end address does not reveal the entire telephony architecture. It does establish that the current public customer journey is not wholly carried by Source2Cloud’s own autonomous system.

That fits a channel model. De Netwerkfabriek, whose logo appears among Source2Cloud’s claimed partners, publishes a case involving a 25-person installation business in Houten. The case combines fibre access, managed Wi-Fi, a Fortinet firewall and “Source2Cloud VoIP”, including softphones for field staff. The channel-published customer account describes the workflow and the claimed improvement in reachability. It does not provide a legally identifiable customer, measurement method or independent customer confirmation, so it should not be treated as audited proof of service quality. It is nevertheless concrete evidence of how the VoIP product is packaged: as one component inside a partner-delivered network solution.

The private-cloud asset boundary is less visible. The company says it uses dedicated local datacentres and, on LinkedIn, describes its own servers and private network in independent Dutch facilities. It does not publicly name those facilities, specify whether it owns or leases each server, identify storage ownership, list carriers or publish colocation certifications.

A local datacentre claim should therefore be translated into an evidence request: facility legal name and address; equipment serial-number or lease schedule; cage or rack control; authorised-person list; remote-hands terms; carrier hand-offs; data location; backup location; and the exact consequence if a facility or upstream contract ends.

Partner capacity is not second-class capacity. It can offer better scale, certifications and resilience than a small provider could build alone. The risk is unacknowledged dependence. A clear proposal can say: Source2Cloud owns these hosts, leases this rack, administers this hypervisor, buys these circuits, resells this telephony platform and remains the single support contact under these back-to-back commitments. That is far more credible than treating “local” as a synonym for owned.

Migration is where the control claim becomes testable

Source2Cloud’s most defensible opportunity is not a generic hosting sale. It is a managed migration for an organisation that wants to reduce dependence on ageing premises equipment or a distant cloud without creating a second integration project. The consulting, network and administration offers cover the entire path. That breadth becomes valuable when it produces durable customer artefacts.

A serious migration begins with discovery. The provider should identify workloads, versions, data volumes, peak demand, latency sensitivity, identity dependencies, certificates, scheduled jobs, inbound and outbound network flows, backup requirements, licensing constraints and business owners. It should map not just servers but the sequence of a business day: which application authenticates first, which file share feeds which process, which telephone number reaches which team, and what must be available before staff can work.

Source2Cloud advertises infrastructure assessments and migration planning. The procurement test is the resulting record. Will the customer receive a machine-readable inventory, dependency map, risk register, target architecture, address plan, migration runbook, rollback decision point and acceptance criteria? Are passwords and encryption keys placed in a customer-controlled vault? Can a different provider understand the environment from the delivered documentation? If the answers are no, the migration may work operationally while increasing switching cost.

The dedicated-host model creates a specific design question. A customer may buy isolation but inherit a minimum hardware step. Capacity cannot always be expanded one virtual processor at a time if the next increment requires another physical host. The provider should show normal and failure-state utilisation, reserve capacity, maintenance placement and what happens when a host fails while another is under maintenance. “Dedicated” is not equivalent to “highly available”; it describes tenancy, not redundancy.

Network transition deserves its own rehearsal. If Source2Cloud can accept a customer network and provide VPN or fibre, a pilot workload can be replicated while the original remains live. The team can test directory services, application latency, monitoring, backup and user access before moving production traffic. Cutover should have an explicit abort threshold, such as an error rate or reconciliation difference, and a time after which rollback is no longer safe. DNS time-to-live, firewall state, route propagation and telephone-number porting each have different reversibility.

Data movement is equally concrete. The bid should state the initial transfer method, encryption, checksum process, delta synchronisation, final freeze, reconciliation and disposal of temporary media. Large datasets may require physical transfer or extended replication; databases may need application-consistent snapshots rather than copied disks. A successful boot is not proof that transactions, permissions and retention rules survived.

The final acceptance test should include failure. Disconnect an upstream. Restore a representative application into an isolated environment. Remove an administrator. Rotate a key. Retrieve logs without provider assistance. Export a virtual machine and its metadata. Redirect a telephone number. These tests are not theatrical attempts to catch a supplier out. They reveal the true operating boundary before an outage or exit makes discovery expensive.

Support is a capacity model

Source2Cloud markets 24-hour monitoring and support, a ticket portal, real-time assistance and local expertise. Its contact page separates sales, support tickets, a control panel and VoIP resources, which suggests an operating workflow beyond a single email inbox. The vocational-training record also describes user questions and service-ticket work. Those are positive indicators of support practice. They do not answer the capacity question.

Small teams can deliver excellent support because context stays close to the customer. A person who designed the network may recognise the impact of a firewall alert immediately. Escalation can be a conversation rather than a transfer between departments. The trade-off is concentration. A two-to-five-person estimate and a LinkedIn range of two to ten do not establish the actual on-call roster, but they make staffing resilience a legitimate question. Round-the-clock monitoring could mean an automated alarm with best-effort response, a staffed rotation, an external network-operations centre or a mixture of all three.

The service level should separate five clocks: detection, acknowledgement, qualified diagnosis, workaround and restoration. “Fast response” measures only one of them unless defined otherwise. A critical database can receive an immediate reply and remain unavailable for hours. The contract should also distinguish an infrastructure failure from an application defect and identify who coordinates when the cause crosses the boundary.

The Voys transaction makes key-person and asset continuity more than a hypothetical issue. A business line moved to a customer that wanted direct operational control, while Dorland stayed involved and continued under Source2Cloud. That history may demonstrate an orderly handover. It also shows that a customer should plan for a future change in ownership, focus or personnel. The plan might include documented secondary administrators, customer-held emergency credentials, configuration exports, a named subcontractor schedule, notification of material ownership change and transition assistance.

No public status history, achieved response distribution or incident report was found in the frozen evidence. That does not mean Source2Cloud has suffered no incidents or manages them poorly. It means a buyer must create evidence during due diligence. Ask for anonymised ticket statistics, two recent post-incident reports, a sample maintenance notice and proof of an out-of-hours escalation. During a paid pilot, open one ordinary request and one simulated urgent request, then compare the observed path with the promised path.

Support quality also depends on the customer. A managed provider cannot restore an application it is not permitted to inspect, nor can it maintain a firewall when nobody approves a change. The responsibility matrix should identify decision makers, maintenance windows, customer response obligations and emergency authority. Direct local support is most valuable when both parties know in advance who can say yes.

The price is a risk allocation

Source2Cloud does not publish a usable cloud tariff. Its pages advertise flexible or pay-as-you-go economics, simple pricing, no hidden fees and no long commitments, while directing the buyer to request a quote. Those propositions could coexist: a tailored private cloud may use transparent metering inside a negotiated agreement. But without a rate card, “simple” remains untested.

Dedicated infrastructure has a different cost curve from a shared public cloud. The provider must reserve enough host, memory and storage capacity for one customer and enough spare capacity to meet its failure promise. A quote may therefore contain a base cluster, storage tier, backup retention, software licences, public addresses, firewall, VPN, cross-connect, bandwidth, support level, monitoring, implementation and optional disaster-recovery location. Some costs are fixed; others depend on usage or change volume. A low headline compute price can be offset by migration labour, licensed backup capacity or a second-site minimum.

The transaction with Voys is a useful economic clue, though not evidence of Source2Cloud B.V.’s pricing. Voys said taking server management in-house expanded its margin. In any managed stack, each operational layer has a price and a reason to exist. A smaller customer may rationally pay Source2Cloud to absorb specialist labour it cannot staff. A large customer with enough scale may save money by internalising that layer, as Voys expected to do. The break-even point depends on workload stability, internal skills, compliance cost and the value of a single accountable operator.

A comparable quote should cover a full term and a full exit. Buyers should request the same workload profile from each bidder, including failure capacity, backup, support and realistic data transfer. The model should identify one-time discovery and migration, recurring minimums, variable charges, annual indexation, vendor licence changes, after-hours work, security-review assistance, restore requests, extra retention, cross-connects, public-cloud consumption and exit support. A “no lock-in” offer should include export labour and transfer media rather than leave them to a later negotiation.

The newer HappyAutomate trade name adds a strategic variable. It may simply broaden Source2Cloud’s consulting work, allowing the same team to automate processes on top of the infrastructure it manages. It may indicate a shift of attention toward AI-enabled business services after the telephony-hosting sale. Public evidence does not show the revenue mix, staffing allocation or product roadmap, so either reading is an inference. A cloud customer should ask which services are core, which personnel are committed to hosting and how investment in the private-cloud platform will be maintained.

Price should finally be tied to control outcomes. A cheaper environment that cannot be exported, audited or restored independently may carry a larger deferred cost. A more expensive local service may be good value if it reduces downtime, removes integration work and delivers reusable documentation. The quote becomes intelligible when every charge maps to an asset, responsibility or risk.

Security claims need an evidence hierarchy

Source2Cloud says its private cloud uses local facilities, firewalls, encryption and strict access control. Its administration page adds threat monitoring, intrusion detection, backups and disaster recovery. These are appropriate control categories. None should be treated as independently verified merely because it appears on a service page.

The first security document should be a data-processing agreement, not a slogan about Dutch storage. The Dutch Data Protection Authority’s GDPR implementation guide describes the expected substance of processor arrangements: subject and duration, nature and purpose, confidentiality, security measures, assistance with data-subject rights and breaches, deletion or return, audit rights and conditions for subprocessors. A local facility may simplify jurisdictional analysis; it does not itself establish lawful processing, adequate access control or compliant retention.

Source2Cloud’s public privacy page is largely a generic website policy about comments, cookies, accounts and embedded content. It does not identify a private-cloud subprocessor chain, service-specific retention, cross-border support, technical measures or customer audit process. That is not proof those documents do not exist. It means the website policy cannot stand in for them. A buyer should request the current service agreement, processing terms, subprocessor list, security schedule and deletion certificate form.

Certification evidence is similarly absent from the public pack. No Source2Cloud certificate for ISO 27001, NEN 7510, SOC reporting or an equivalent scheme was located. Absence from a public website is not proof that the company or its facilities lack certification; some suppliers provide certificates under confidentiality. The procurement distinction is between a facility’s certificate, a technology partner’s certificate and a certificate whose scope covers Source2Cloud’s own management system and the contracted service. Each answers a different question.

The network registry supplies one narrow, positive control: a valid route-origin authorisation for the identified Source2Cloud prefix. Yet the route was not observed at the article date. Security evidence has to be both scoped and operational. In the same way, an encrypted backup is useful only if keys are available during recovery; multi-factor authentication is useful only if emergency accounts and automation paths are covered; a penetration test is useful only if its scope reaches the exposed service and findings are remediated.

Regulatory pressure is rising. The Netherlands announced that its Cybersecurity Act, implementing the NIS2 framework, will enter into force on August 15, 2026. The government notice describes registration, duty-of-care, incident-reporting and governance obligations for covered essential and important organisations. On July 17 the law was enacted but not yet in force. Public evidence does not establish that Source2Cloud itself falls within scope. Customers that do will nevertheless need supplier information quickly enough to assess risk and report incidents.

A proportionate due-diligence pack for a small provider need not mimic a hyperscaler’s library. It should at least contain an architecture and data-flow diagram, control ownership, access-review evidence, vulnerability and patch process, backup and recovery results, incident procedure, subprocessor list, staff screening and confidentiality controls, facility assurance, insurance, business continuity and a remediation record from an independent technical test. Where a document cannot be shared, the provider can allow supervised inspection or an auditor’s summary.

The goal is not paperwork volume; it is a traceable path from claim to control to evidence.

The exit route is part of the service

European cloud policy has made switching a current contractual issue. The EU Data Act has applied since September 12, 2025. The European Commission’s explanation of the Act says cloud and edge providers must remove obstacles to switching, support data and application portability, make contracts transparent and progressively remove switching charges; those charges are due to disappear entirely on January 12, 2027 after an interim period limited to cost recovery.

Dutch market research shows why legal rights do not remove engineering work. In April 2026, the Authority for Consumers and Markets reported a survey of 420 business cloud users. The ACM study found that 61.7 per cent had never switched provider; among respondents who had tried, 30.2 per cent did not complete the switch. A quarter of those who tried to connect services from different providers failed. Awareness of the Data Act was low. These are market-wide findings, not measurements of Source2Cloud.

Source2Cloud’s “no long-term lock-ins” claim is therefore best tested as an engineering property. Contract term is only one form of dependence. Data may be exportable while identity mappings, firewall rules, monitoring history, telephone numbers, backup chains and operational knowledge remain trapped. A customer using a dedicated host may avoid proprietary hyperscale services but still depend on a particular virtualisation format, storage feature or administrator.

An exit schedule should be agreed before entry. It should list export formats, metadata, configurations, logs, keys, documentation, telephone-number procedures, assistance rates, transfer bandwidth, deletion timetable and continued service during transition. It should say whether customer-owned addresses can move, whether licences can be reassigned and how a final backup is verified. The customer should receive recurring configuration exports during the term, not discover at exit that only the provider has a current copy.

The strongest proof is an exit rehearsal. During the pilot, export one representative virtual machine, restore a database elsewhere, recreate a firewall rule set, retrieve audit logs and demonstrate control of an identity account. Measure time, required privilege and manual intervention. If the proposed stack uses open or widely supported formats, the result should be straightforward. If it depends on a provider-specific feature, both parties can price that dependence consciously.

The Data Act does not make every migration easy or every charge unlawful. It creates a baseline against obstructive contractual and technical practices. A good small provider can go further by making reversibility a selling point: customer-readable designs, standard tooling, routine exports and a pre-priced handover. That would turn Source2Cloud’s anti-lock-in language from marketing into a measurable advantage.

Competition is a choice of control plane

Source2Cloud does not compete only with other small Dutch hosts. A buyer can place virtual machines with a hyperscaler, rent a managed private cloud from a larger domestic operator, buy colocation and hire administrators, retain hardware on premises, or use a specialist managed-service provider on top of public cloud. Each option moves the control plane.

Hyperscalers offer geographic breadth, automation, deep managed services and enormous capacity. They also expose customers to complex consumption pricing, shared-responsibility boundaries and service-specific dependence. A larger Dutch managed-cloud provider may offer named facilities, formal assurance and broader staffing at a higher minimum or with less personal flexibility. On-premises systems provide physical proximity but leave lifecycle, power, security and recovery with the customer. Colocation separates the facility problem from the operating problem and creates another interface to govern.

Public disclosure is itself a competitive signal. Fundaments, for example, names Dutch Tier 3 or better facilities and lists ISO 9001, ISO 14001, ISO 27001, NEN 7510 and ISAE 3402 in its private-cloud material. Its managed-cloud page describes responsibility through operating-system, database and application layers and advertises response and resolution commitments. These are supplier claims, not proof that Fundaments is the right alternative or that every certificate covers every service. They show the level of specificity against which any managed-cloud bid can be compared.

Source2Cloud’s potential advantage is a tighter loop between migration design and operations. Its offer can accommodate a customer network, dedicated hosts, hybrid connections and local administration; its channel case suggests it can fit inside a wider connectivity and telephony solution. The exact company retains its own registry identity and technical competence after the Voys-serving business moved through the separate Source2Cloud Services transaction. For a buyer underserved by a large catalogue, that can be meaningful.

Its disadvantage is the present public evidence gap. Facility identity, active route use, platform specification, service-level terms, certifications, verified customer outcomes and price are not visible enough to compare without a private diligence process. A confident supplier should be able to close that gap in a structured bid. If it cannot, the buyer is being asked to purchase intimacy without observability.

The competition should therefore be designed around outcomes rather than labels. Give bidders the same workload, recovery target, data-location rule, administration boundary and exit test. Compare total cost under normal operation, a host failure, a security incident and a migration away. The winner may be a local dedicated cloud, a public platform or a mixed design. The useful question is not which one is “sovereign” in the abstract. It is which control plane the customer can understand and exercise.

A procurement test that can produce a “no”

A fair procurement process for Source2Cloud should be demanding enough to reject the offer, because a test that can only confirm the sales narrative reveals little. It can proceed in five gates.

The first gate is identity and chain of custody. The bid should name Source2Cloud B.V., Chamber of Commerce number 60404558, as contracting party or explain any other party. It should list trade names, beneficial control, insurance, financial counterparties and every subcontractor touching service data or production operations. A separate schedule should identify assets and contracts relevant to the proposed environment and state whether any came from, went to or are shared with the former Source2Cloud Services operation.

This is not an accusation about the transaction; it is how the buyer prevents a familiar brand from obscuring a changed responsibility.

The second gate is architecture. Source2Cloud should provide a customer-specific diagram from facility and carrier through compute, storage, virtualisation, network, backup, identity, monitoring and support. Each component should carry four labels: owner, operator, data location and failure dependency. Dedicated-host isolation, spare capacity, maintenance behaviour and recovery location should be explicit. If AS209223 will be used, the bid should show current route visibility and upstream design. If it will not, the partner network should be named.

The third gate is operating evidence. The buyer should inspect a recent access review, patch report, restore result, incident example and change record. It should call the support path outside normal hours by agreement. The parties should walk through a host failure, storage corruption, carrier outage, lost administrator, ransomware event and facility loss. The exercise should identify who detects, who decides, who communicates and who has authority to restore.

The fourth gate is commercial completeness. The price model should cover design, migration, minimum capacity, failure reserve, licences, traffic, cross-connects, backup, monitoring, support, security assistance, change work, indexation and exit. Service credits should not be the sole remedy for a failure that threatens the customer’s business. Liability, insurance, data breach cost, customer-caused incidents and third-party changes need intelligible allocation.

The fifth gate is a paid pilot with a reversible cutover. Move a representative but bounded workload. Test performance at peak, patching, backup, restoration, monitoring, user administration and the real support route. Then export the workload and documentation to a customer-controlled destination. The pilot passes only if both operation and exit meet pre-agreed measures.

These gates also protect Source2Cloud. They prevent a customer from assuming that “fully managed” includes an application the supplier has never seen, or that a low-cost quote includes unlimited architecture work. They expose customer-side delays, unsupported software and unrealistic recovery demands before the production contract. A small provider benefits when responsibility is precise.

If Source2Cloud cannot prove physical ownership, that need not be fatal; the proposal can rely on leased equipment with sound contracts. If AS209223 remains unannounced, that need not be fatal; the service can use resilient partner routing. If certification is absent, that need not be fatal for every customer; compensating evidence may be sufficient. The fail condition is a material claim that cannot be scoped, evidenced or contracted after a reasonable diligence process.

The watchpoints after signing

The first watchpoint is routing. A renewed, stable announcement of the Source2Cloud prefix, visible through multiple collectors and protected by consistent route-origin authorisation, would show that the registered network option is again in active use. It would still be necessary to connect that route to the customer service. Continued absence would make partner-network disclosure more important, not automatically make the service unreliable.

The second is infrastructure disclosure. Named Dutch facilities, platform versions, resilience design and the split between owned, leased and partner assets would materially improve confidence. So would an explanation of what was retained after the Voys transaction and what has been built since. A public asset list is not required, but a customer under confidentiality should receive one for its service.

The third is assurance. A scoped certification, independent test summary, recovery exercise, availability history or detailed security paper would move several claims from assertion toward evidence. The quality of remedial follow-through matters more than a badge by itself.

The fourth is customer proof. The De Netwerkfabriek case demonstrates a plausible VoIP workflow, but an identified private-cloud migration with before-and-after architecture, downtime, recovery and customer confirmation would be much stronger. An anonymised case can still be useful if the measures and verification method are concrete.

The fifth is strategic focus. HappyAutomate may enrich the offer by bringing workflow design closer to infrastructure, or it may compete for the attention of a small team. Customers should monitor staffing, platform investment and the proportion of support delivered by named employees and partners. A change in trade-name emphasis is a signal to ask questions, not a verdict.

The sixth is documentation drift. Architecture, administrators, subprocessors, recovery procedures and exit exports should be reviewed on a schedule and after material changes. The best procurement pack loses value if it describes last year’s network. A quarterly service review should compare the live environment with the contracted map and record exceptions.

These watchpoints are observable. They allow a buyer to update its view without waiting for a public crisis or a renewal negotiation. They also give Source2Cloud a path to demonstrate progress through evidence rather than broader adjectives.

Control is the deliverable

Source2Cloud B.V. is not the three-datacentre telephony business that Voys brought in-house, though its history and people meet at that transaction. It is the smaller company that continued: legally distinct, technically active, still holding internet resources, selling private cloud and administration, participating in a partner-delivered VoIP workflow and opening a new automation front.

That makes it more interesting than a generic local host and harder to assess than a provider with extensive public assurance. The sale stripped away the temptation to equate a familiar name with an unchanged asset base. The current routing state strips away the temptation to equate an assigned ASN with a live independent network. The public partner endpoints strip away the temptation to equate local service with end-to-end ownership. Each correction leads to the same place: control must be demonstrated layer by layer.

For the right customer, a small Dutch operator can still be the rational choice. Direct access to engineers, dedicated hosts, custom networks and one team across migration and operations may reduce coordination cost and make infrastructure more intelligible. The benefit is strongest when Source2Cloud turns its closeness into documentation, measured support, transparent dependencies and a rehearsed exit.

The company’s proposition should therefore be bought neither on trust alone nor on suspicion created by missing public paperwork. It should be bought through proof. Identify the company. Trace the assets. Name the partners. Test the cutover. Restore the data. Call the support line. Export the workload. Price the handover. When those actions succeed, “private cloud” stops being a location or a slogan. It becomes what Source2Cloud is really offering: a transfer of operational control that the customer can see, govern and, if necessary, take back.