The 2 A.M. Ledger: SaaSplaza, InTWO and the Control Bargain Behind Dynamics Cloud

Summary

• The documented journey of SaaSplaza to InTWO is a continuity of Dynamics and Azure operations, people and sites, but public evidence does not establish that the historical US company is the contracting party for each current InTWO service.
• The managed cloud bargain replaces server ownership with a division of control: Microsoft manages parts of the platform, InTWO proposes to coordinate infrastructure and application operations, and the customer remains owner of data, identities, business configuration and critical acceptance decisions.
• InTWO publicly describes a broad operational surface — migration, Azure operations, Dynamics support, upgrades, integrations, backup and recovery — but its public pages do not disclose a standard price list, full service schedule, audit scope, subcontractor list or tested exit procedure.
• Defensible procurement therefore tests business-process recovery, update readiness, incident evidence, tenant and subscription control, economic transparency and exit artefacts before considering "a single point of contact" as equivalent to a single point of responsibility.

At 2 A.M., Three Parties Own the Failure

Imagine a manufacturer closing its month. This is a hypothetical operational test, not an InTWO customer incident report. At 2 A.M., purchase orders still appear in Microsoft Dynamics 365, but the warehouse cannot release them. A recent application update changed behaviour at the edge of a custom workflow; an integration rejects messages; an Azure-hosted component is healthy in isolation. The Microsoft service dashboard is green. The managed service helpdesk sees alerts. Only the customer's finance and distribution teams know which delayed transaction will stop a truck at dawn.

Who owns the failure?

The answer may be "all three" without being evasive. Microsoft controls the service code and the cadence of parts of Dynamics 365. A specialised operator may control monitoring, incident triage, Azure resources, deployment pipelines, support escalation and some application changes. The customer controls user access, business priorities, data management, acceptance criteria and often the contract with each software vendor. An independent software vendor may control the faulty extension. A systems integrator may still hold undocumented design knowledge.

Each entity can fulfil a narrow technical obligation while the order-to-cash process remains broken.

That is the problem InTWO sells against. Its current pages offer managed Dynamics work covering implementation, configuration, customisation, integrations, maintenance, backup and recovery, as well as managed Azure operations covering compute, networking, storage, access and incident response. The company presents this as a way to create a single operational relationship across a fragmented Microsoft estate. Itsdescription of managed Dynamicsand itsdescription of Cloud Managed Opsare useful maps of the intended surface, but they are vendor descriptions, not evidence that every customer buys every component or receives the same contractual promise.

The thesis of this article is narrower than "outsourcing is convenient" and more consequential. The SaaSplaza/InTWO proposition is a control bargain. A customer gives a specialised operator persistent access, operational discretion, workload knowledge and a privileged place in the escalation chain. In return, it expects the operator to close gaps between the application, infrastructure and Microsoft support faster than an internal team could.

The bargain only succeeds when the operator's authority matches its responsibility and the customer retains enough evidence and technical control to verify performance, intervene in emergencies, and leave.

This distinction matters because availability at one layer is not business continuity. InTWO's Dynamics page advertises "99% application availability" and "up to 40%" total cost of ownership reduction. These arecompany marketing claims, not independently measured results or a public standard contract. If 99% were measured continuously over a non-leap year without exclusions, the downtime allowance would be about 87.6 hours. An actual agreement may use a different denominator, exclusions, maintenance windows and service credits. The procurement question is not whether 99 sounds high. It is what is measured, where, over which hours, for which dependencies, and what happens when Dynamics is technically reachable but a critical business process is not.

The most valuable thing a managed operator can provide at 2 A.M. is therefore not a server or a slogan. It is an evidence-based decision path: a shared definition of impact, telemetry across the relevant layers, a named authority to make a change, a route to Microsoft or an extension vendor, and a tested way to restore the transaction. That is the ledger by which continuity from SaaSplaza to InTWO should be evaluated.

The Inc. Is Real; the Brand Has Evolved

Legal and operational identity requires care because "SaaSplaza", "SaaSplaza Inc." and "InTWO" are related but not interchangeable labels.

The strongest public bridge begins with audited corporate reports. RIB Software SE's2018 annual reportstates that RIB acquired 100% of the SaaSplaza group in November 2018. It identifies the parent company as SaaSplaza International B.V. in Amsterdam, describes the group as a Microsoft Azure and Dynamics cloud provider, and lists offices in San Diego. The subsidiary table namesSaaSplaza Inc., Encinitas, San Diego/USA, with 100% ownership. RIB's2020 annual reportagain lists SaaSplaza Inc. in Encinitas as a wholly owned group company. These are far stronger identity records than a reseller directory or a brand biography: they prove the exact US company existed within the acquired group through the end of 2020.

The next step is operational continuity. In July 2021, trade publications reported that five RIB companies—ICS Support, Intech, Levtech Consulting, RIB Cloud and SaaSplaza—had been combined under the name InTWO.Dutch IT Channeldates the combination to 1 July and describes SaaSplaza as bringing its Microsoft Azure expertise and managed business applications.Channel Post MEAindependently reported the same five-company combination and the intention to provide a broader Microsoft cloud portfolio. These are reports of a corporate announcement, not statutory merger documents, but they establish the public brand transition.

InTWO itself provides two further links. A 2022 customer announcement for Kingfisher calls the company "InTWO, formerly SaaSplaza" and says the customer renewed a relationship for managed Azure infrastructure and Dynamics support in Asia-Pacific. The current leadership page shows that US managing directorOlivier Meynierspent ten years as managing director of SaaSplaza Americas and now oversees InTWO's operations and service delivery from San Diego. The combination of an explicit former-name statement, a continuing customer relationship, the same operating city and the continuity of senior personnel is compelling evidence that SaaSplaza's US operation fed today's InTWO services organisation.

There is also a technical historical trace. IP registry aggregation atIPinfo for AS393318records "SaaSplaza, INC" in the United States and an assignment date in 2013. It currently marks the autonomous system as inactive and shows no announced address space. This record is corroborating, not decisive: it supports the exact historical operational name, while its inactivity warns against assuming the former company still presents itself as an autonomous network operator.

The limit is just as important. The public sources reviewed do not provide a current US registry extract, a current group subsidiary schedule, a standard customer contract or a legal opinion that SaaSplaza Inc. is the contracting entity behind every InTWO engagement in the United States in 2026. InTWO's public website shows operations in San Diego and Amsterdam, but brand and service continuity do not themselves prove current legal capacity. The evidence reviewed also does not support inserting another better-known managed services company into this chain.

The substantiated bridge is the SaaSplaza group, including the exact US Inc., into the operating brand InTWO.

That makes the honest boundary fairly precise. SaaSplaza Inc. is the historical US legal anchor. SaaSplaza's Dynamics and Azure practice is a documented predecessor of InTWO. InTWO is the current service surface. A buyer must still ask which legal entity signs its order, employs or subcontracts the delivery team, holds the Microsoft partner and cloud solutions provider responsibilities, carries insurance, owns the service credits and remains liable after termination. A purchase order addressed to a brand does not replace that schedule.

From Hosting Stack to Coordination Stack

SaaSplaza's history helps explain why InTWO's current documents cover so many layers. Microsoft'spartner case studystates that SaaSplaza started in 1998 as a generic hosting provider and refocused in 2008 on Microsoft Dynamics in the cloud. It describes support for Dynamics AX, NAV and GP in Azure regions, subscription-based provisioning and follow-the-sun support. The study also relayed a company executive's claim that an automated dealer management environment could be provisioned in under six minutes. This figure should be read as a dated vendor success claim, not a general benchmark. The more durable fact is the operational model: SaaSplaza was trying to industrialise repeatable Dynamics environments rather than renting undifferentiated server space.

A 2012 announcement from BDO illustrates the division of labour. BDO said it would combine its Dynamics ERP and CRM implementation expertise with SaaSplaza's infrastructure, services and support. Theannouncementcame from the vendors and predates today's Azure architecture and Dynamics 365 SaaS model, so it cannot prove current performance. It nevertheless shows a durable customer workflow: one party translates business requirements and configures ERP; another operates the underlying platform; the customer needs both to behave as a single service.

RIB's 2018 report gives a less promotional description of the acquired service. It states that SaaSplaza's managed services covered performance monitoring, backup and recovery, ongoing support, incident handling, environment maintenance, updates and migration. This list is significant because it already crossed the line between infrastructure and application lifecycle. By the time the brand entered InTWO, the acquired operational competence was not simply rack space. It was the ability to keep a specialised enterprise application running through change.

Automation was also commercial, not just technical. AKeenondots customer casestates that SaaSplaza used a CloudBlue commerce platform to automate ordering, provisioning and billing of Microsoft services across resellers and end customers, including multiple currencies and tiers. This is a vendor's account of its own customer and does not reveal SaaSplaza's full billing architecture. It nevertheless shows why the earlier platform mattered: the provider needed mechanisms to turn a bespoke ERP estate into a repeatable subscription that partners could sell.

InTWO's current proposition is broader. Itscompany descriptionpositions Azure, Dynamics and security in a Microsoft-centred portfolio and claims more than 400 customers in 40 countries. These customer and geography numbers are company claims; no current audited breakdown was found. The services pages now speak of advisory, architecture, migration, operate and improve. InTWO calls this sequence CloudCARE: consult, architect, run and improve. The shift is from owning a hosting stack to coordinating a cloud stack whose underlying control planes often belong to Microsoft and the customer.

This changes what "managed" must mean. In a traditional hosted AX environment, a provider could control virtual machines, operating systems, database operations, backup tasks and the network perimeter. In Dynamics 365 as a service, Microsoft controls much of the platform and release machinery. The operator creates value by governing the interfaces: the Azure components alongside Dynamics, identity and access, monitoring, extensions, testing, incident escalation, costs and customer communication. The customer no longer buys the provider's cloud in a simple sense.

It buys the provider's ability to function coherently across multiple clouds and contracts.

This is potentially a stronger service, because integration failures rarely respect vendor boundaries. It can also be harder to audit. When the same provider recommends architecture, resells cloud consumption, runs the environment, reports its performance and proposes the next optimisation project, convenience and information asymmetry rise together. The remedy is not to reject an integrated operator. It is to keep architecture decisions, telemetry, invoices, change records and acceptance evidence visible to the customer.

What Crosses the Migration Boundary

"Moving Dynamics to the cloud" sounds like a location change. In practice, it is a renegotiation of dependencies.

InTWO'scloud migration pagedescribes assessment, dependency analysis, a test environment, validation and a choice between rehosting, refactoring and rearchitecting. Its Dynamics upgrade page addscustomisation assessment, data migration, testing, training and ongoing updates. These are sensible steps, but they are descriptions of a process offered. They do not disclose acceptance thresholds, staffing, tools, failure rates or typical durations a buyer would need to evaluate delivery.

Microsoft's own implementation guidance is more useful as a neutral framework. TheDynamics 365 implementation guideorganises work into strategy, initiation, implementation, preparation and operate phases. Itsenvironment strategy guidenotes that an environment carries far more than records: it includes the data model, application metadata, process definitions and security constructs. That means a migration inventory should start with business capabilities and control state, not a server count.

Several different transitions may be hidden within a single programme:

1. An older Dynamics AX, NAV or GP deployment may move from customer-owned or vendor-hosted infrastructure to a newer Azure architecture.
2. Business functionality may move into Dynamics 365 as a service, changing who patches the underlying platform and how releases arrive.
3. Interfaces, reports, scheduled processing, files, identity services or industry extensions may stay in Azure infrastructure or move to platform services.
4. Microsoft licensing and Azure consumption may move into a cloud solutions provider relationship managed by InTWO.
5. Application support may move from an implementation partner or internal team to InTWO even when the tenant and subscription do not move.
6. Operational knowledge may move informally through runbooks, tickets and staff handovers whether or not the contract calls it a deliverable.

Each transition has a different acceptance test. Data reconciliation can prove that balances and open orders arrived. It does not prove that month-end close meets its former window. A successful connection does not prove that segregation of duty controls survived. A green integration point does not prove that every message was processed once. Infrastructure recovery does not prove that a carrier label, a tax calculation or a bank file can be produced. "Migration complete" is therefore a set of assertions that should be signed off by named process owners.

The Kingfisher announcement offers a current illustration, with limits. InTWO states that the retailer selected it to support infrastructure, applications and Dynamics 365 across four Asia-Pacific sites, following an earlier relationship under the SaaSplaza name. It also reports expected performance and cost improvements. Because this is the provider's announcement and does not publish architecture, contract or independent customer metrics, it proves the service model was sold; it does not validate the claimed outcome.

The useful clue for procurement is the scope: global ERP continuity may require regional Azure design, application knowledge and support coordination simultaneously.

A rigorous migration plan should freeze a baseline before the move: transaction volumes, close duration, critical interface success rates, scheduled task completion, latency by location, support demand, recovery evidence and total cost. It should then define who can accept deviations. If the operator measures only resource availability while the customer cares about shipment release, both can declare success and disagree on continuity.

The boundary should also preserve customer control. Microsoft states that cloud responsibility varies by service model, but the customer always retains responsibility for its data, identities, configurations and access management. In infrastructure as a service, the customer side also remains responsible for operating systems and applications unless it delegates those tasks to a managed provider. Microsoft'sshared responsibility modelmakes delegation visible as a commercial choice; it does not transfer ultimate liability to the platform provider.

For InTWO, the strongest migration proposal would therefore describe not only what its team will do, but the exact control state after handover: who owns the tenant and subscriptions, which roles are delegated, where source code and deployment definitions live, which party approves production changes, who sees native Microsoft logs and invoices, and which artefacts the customer can take away without assistance. These questions turn a move into an operational design.

One Front Door, Multiple Control Planes

InTWO's value proposition frequently returns to a single point of contact. That is appealing because a Dynamics estate may contain at least six technical and commercial control planes.

The first is identity: Microsoft Entra accounts, privileged roles, conditional access policies, service principals and emergency access. The second is the Dynamics application: modules, roles, workflows, extensions and data. The third is Power Platform and Dataverse, where automations, integrations and low-code components may live. The fourth is Azure, which may host interfaces, virtual machines, storage, networking, analytics and recovery components. The fifth is the software delivery chain: source control, build artefacts, test suites and release approval.

The sixth is commerce: Microsoft licences, Azure consumption, reservations, marketplace products and managed services fees.

InTWO's Cloud Managed Ops page states that it can manage compute, virtual networks, subnets, access control lists, storage, recovery vaults, business continuity, patching, Microsoft support, cloud subscriptions and role-based access control. It also states it uses least privilege and offers response commitments based on severity. These are substantive statements about the service offered, but the page does not expose standard role definitions, a response time table or escalation schedule. A customer must translate the list into a responsibility matrix for its own estate.

"One front door" works when the desk has the authority, context and telemetry. It fails when it is only a routing layer. For a priority incident, the customer should know whether InTWO can roll back its own deployment, open a Microsoft severity case, disable a failing interface, invoke an extension vendor, approve an emergency cost, communicate with business owners and preserve forensic evidence. If it must ask the customer for every action, the response target should reflect that dependency. If it can act without asking, change and access controls should reflect the risk.

A customer-owned control plane can reduce dependency without preventing managed service.Azure Lighthouseallows a service provider to manage delegated cross-tenant resources while the customer retains boundary control, can audit provider actions in the Azure activity log and can remove access. There is no public evidence in the reviewed material that every InTWO customer uses Lighthouse, so it should not be assumed. It is rather an architecture test: can InTWO deliver the desired operational scope through revocable delegation within customer-owned subscriptions, or does the service require resources and billing relationships that are harder to transfer?

The same principle applies to monitoring and automation. The operator may have a superior multi-tenant platform, but the customer needs access to raw or exportable event history, configuration and runbooks. A dashboard visible only during the contract cannot prove past performance after a dispute. Automation whose source, trigger and rollback method are opaque is additional dependency, even when it reduces labour.

The correct operational goal is not customer micromanagement. It is observable delegation. InTWO should be free to execute agreed routine work quickly; the customer should be able to see what was delegated, what changed, what evidence supports the outcome and how to revoke privilege. That arrangement gives the operator freedom to operate without turning convenience into custody.

The Update Calendar Now Drives Operations

Dynamics cloud operations are not a steady state. Microsoft's release cadence makes change part of the service.

For Dynamics 365 Finance and Operations, Microsoft guidance states that service updates occur four times a year—in February, April, July and October—and customers must take at least two updates per year. Only one consecutive update can be paused. Theservice update guidetherefore recommends a recurring discipline of release planning, regression testing and user acceptance rather than long-term version freezes. Microsoft'spause documentationalso records a current operational transition: from February 2026, new customers manage updates via the Power Platform admin centre rather than the older Lifecycle Services path.

This cadence is a central part of the InTWO bargain. Its managed Dynamics and upgrade pages offer ongoing updates, hotfixes, testing and support. The provider can pool expertise across customers, maintain release knowledge and automate repetitive validation. That is a plausible economy of scale. It does not remove the customer's responsibility to decide whether an invoice, a price calculation, a regulatory report or a warehouse process still behaves correctly.

The critical artefact is a business-risk-linked regression catalogue. It should distinguish:

• provider platform tests from customer process tests;
• automated tests from manual acceptance;
• Dynamics core behaviour from extensions and integrations;
• technical success from financial reconciliation;
• a successful test from a promoted production release;
• a customer-code rollback from a Microsoft service change that cannot simply be undone.

Automation can shrink the time between release and proof, but only for the cases it actually covers. A high automated pass rate can coexist with a serious failure in an unmodelled process. Buyers should ask for the inventory of covered processes, its latest execution results, ownership of test scripts, test data handling, false-positive history and the procedure to add a regression after an incident.

The cadence also changes support economics. Managed service fees may include a standard amount of release preparation while charging separately for fixing custom code, an obsolete extension or a new Microsoft feature. Without a clear baseline, "staying current" can turn into a sequence of projects. The contract should state which work is routine maintenance, which is defect correction, which is customer change, and which is caused by a third-party product.

Microsoft's tool transition from Lifecycle Services to Power Platform admin centre is a small example of a larger monitoring point. Automation, runbooks and operator roles must evolve when Microsoft changes the management plane. A customer evaluating InTWO should ask for evidence of that evolution: updated standard operating procedures, tested access, staff training and a completed release cycle in the new tool—not just assurance that the team follows Microsoft's roadmap.

The operational advantage of a Dynamics specialist is therefore measurable. It is the time and quality with which the provider turns an external release into a customer-specific impact assessment, a successful material-process suite, a controlled deployment and an usable record. If InTWO can demonstrate that chain, the customer buys continuity. If it can only show that hotfixes were applied, it buys administration.

Integrations Make the Tenant a System

An ERP tenant is rarely the whole of a company's operating system. Banks, tax engines, warehouses, e-commerce sites, identity services, data platforms, document services, carriers and industry extensions surround it. That is where a nominally standard cloud application becomes customer-specific and where switching costs accumulate.

InTWO states that its managed Dynamics service covers integrations and independent software vendor applications as well as custom modules, workflows and reports. This breadth is important because an application-level incident may originate outside Dynamics. It also creates a demanding knowledge obligation: the provider needs an authoritative interface catalogue, message ownership, identifiers, retry rules, data classifications, maintenance windows and contacts for other vendors.

Microsoft provides programmatic paths for moving data. TheFinance and Operations Data Management APIsupports data packages and recurring integration scenarios. This proves an extraction path exists; it does not make a functional system portable. An export can omit executable business logic, interface behaviour, security design, report definitions, pipeline configuration and tacit choices embedded in years of tickets.

The provider should therefore monitor outcomes, not just endpoints. A successful HTTP response does not prove full posting in the ledger. A queue depth does not identify a duplicate payment. A scheduled task marked complete does not prove every source file arrived. Good operational design attaches technical telemetry to control totals and business exceptions, then assigns someone who can interpret them.

This is another place where SaaSplaza's earlier automation history is relevant but not conclusive. The Keenondots account of automated subscriptions and provisioning suggests familiarity with multi-tier service orchestration. It does not establish how InTWO currently monitors a customer's specific integrations. Procurement needs a demonstration using the buyer's own critical path: inject a controlled failure, observe detection, classify impact, trace the message, invoke the right provider, recover without duplication and reconcile the business outcome.

The exit implications are equally direct. The integration catalogue, interface specifications, certificate inventory, transformation logic, source code, build instructions and operational history should be contractual deliverables under customer control. Otherwise, every successful custom connection increases the cost of replacing the operator who built or learned it.

A Helpdesk Must Produce Evidence

24/7 support is one of the most consistent claims in the SaaSplaza and InTWO records. The historical Microsoft case study described follow-the-sun coverage. The RIB acquisition report described ongoing support and incident handling. InTWO's current pages promote 24/7 global operations. This continuity is credible as an offered capability. Its value still depends on what happens after someone answers.

Three clocks should be separated.Response timeends when the provider acknowledges and begins addressing an issue.Restoration timeends when the material service or a safe workaround is available.Resolution timeends when the underlying defect is fixed or accepted. A contract can meet an aggressive response commitment while a business process remains unavailable for hours. Service credits may also be capped too low to change behaviour. Buyers should map each clock to severity, coverage hours, exclusions, evidence and escalation.

Severity itself can become contested. An operator may categorise by technical scope; the customer may categorise by business deadline. A failing interface might be a low-volume alert yet prevent all payroll payments. The agreement should allow the customer to declare material business impact, require timely joint reassessment and prevent silent severity downgrades. It should state which party can invoke a critical Microsoft case and whether InTWO's promised response stops while waiting for another provider.

InTWO's Cloud Managed Ops page states that premium Microsoft support and escalation are part of its service surface. This can be valuable: a provider familiar with the architecture can pack evidence and reach the right Microsoft queue faster. But it adds another evidence requirement. The customer should receive the Microsoft case identifier, timestamps, diagnostic submissions, current owner, workaround and closure justification, subject to legitimate security restrictions. "Waiting for Microsoft" is a status, not a root cause.

The 99% application availability claim illustrates why a public percentage is limited public evidence. Buyers should ask:

• Is the unit a Dynamics tenant, an Azure component, an interface or a named business service?
• Is availability measured by InTWO monitoring, Microsoft telemetry or an external probe?
• Are planned maintenance, Microsoft incidents, customer changes and third-party failures excluded?
• Does partial degradation count?
• Is the clock running continuously or only during service hours?
• Are restoration time and data loss measured separately?
• Are credits automatic, and do chronic breaches create termination rights?

The answer should be a service level schedule and a monthly evidence dossier, not a sales deck. The dossier should reconcile alert history, ticket timestamps, customer-declared impact, Microsoft cases, maintenance, repeated incidents, restoration performance and agreed exclusions. It should retain raw records long enough for trend analysis and dispute.

Problem management is the higher-order test. A competent desk does not just close tickets; it identifies recurring causes, assigns corrective work and proves the failure is less likely to recur. A useful quarterly review would show repeated incidents by process, escaped release defects, automation coverage, ageing issues, capacity risks, privileged access exceptions, cost anomalies and unresolved vendor dependencies.

No public source reviewed provides InTWO's standard severity table, contractual response and restoration targets, service credit regime, customer-level performance data or problem backlog. This is an absence of evidence, not evidence of weakness. The proper conclusion is that support quality must be demonstrated as part of due diligence and customer references rather than inferred from 24/7 language.

Recovery Starts with the Business Process

Backup is necessary, but "we have a backup" is not a continuity plan.

InTWO'sbackup and recovery pagestates that it uses encrypted and isolated backups and designs recovery around customer needs. It correctly frames the goal as restoring operations, not simply restarting a server. The page does not publish standard recovery point or recovery time objectives, test frequency, geographic design or results. These belong in the customer-specific architecture and contract.

Microsoft platform rules may constrain what a provider can promise. For Power Platform and Dataverse environments, Microsoft'sbackup and restore documentationstates that system backups are normally retained for seven days, with managed production environments configurable up to 28 days. It states that offline database backup download is not supported, larger restores may take more than a day, restore occurs in the same region, and apps and flows are only included when part of a Dataverse solution. These are current platform characteristics, not necessarily the full design of any InTWO customer.

The procurement consequence is straightforward. An operator cannot contract beyond a platform limit simply by promising diligence. It must design additional controls where the business requirement exceeds native capability and prove those controls work. Recovery objectives should identify the exact process and data boundary, not "the cloud."

A credible rehearsal would start with a scenario: corrupt master data during close, a failed extension deployment, loss of an Azure integration region, compromised admin credentials or an unavailable third-party service. It would then measure detection, decision time, clean recovery point, restore duration, interface resynchronisation, security revalidation, financial reconciliation and return to normal operation. The exercise should expose steps that require Microsoft or another provider and whether those dependencies have their own time commitments.

The customer also needs to know who can authorise destructive recovery actions, how clean backups are protected from compromised identities, where encryption keys and recovery credentials live, and whether InTWO staff can execute when customer staff are unavailable. A recovery plan that depends on a named consultant or an unreachable tenant owner is not resilient.

Finally, test results must travel with the service. The customer should receive the scenario, architecture state, timestamps, exceptions, evidence and corrective actions. Otherwise, a successful annual exercise becomes a provider memory rather than customer assurance. Recovery is where the control bargain is most literal: the operator needs enough authority to act quickly, while the owner needs enough visibility to know what will be restored and what might be lost.

Security Assurance Stops at Its Boundary

Managed operations require privileged access to a system containing financial, customer, employee and commercial data. That makes the provider part of the security architecture, not an external helpdesk.

InTWO'ssecurity and compliance pagestates that an independent auditor performs an annual SOC 1 Type II examination and that customers may request the report. It describes a security board and states that sub-processor and subcontractor agreements are used for European data protection obligations. Itsgovernance pagerefers to more than 40 active controls in HR, operations and security. All these statements are company claims until the underlying report, scope and contractual documents are reviewed.

Wording matters. A named assurance report is not a universal certification of the entire company, every office, every subcontractor, every service and every customer configuration. A buyer should inspect the legal entity and services in scope, examination period, system description, locations, subservice organisations, complementary customer controls, exceptions, management responses and any gap between the report end date and service start. It should ask for a bridge letter if applicable and map each relevant control to the purchased service.

The public material reviewed did not establish a current SOC 2 report, an ISO 27001 certificate covering the offered service, a complete subcontractor list, a standard data processing agreement, penetration test results or a public vulnerability disclosure process. This sentence should not be read as a claim that none exist. It means none were established in the frozen public evidence record, and buyers should ask rather than assume.

Microsoft's shared responsibility model remains important even when InTWO is engaged. Microsoft secures the underlying cloud according to the service model. The customer remains responsible for data, identities, accounts, devices and configurations. A managed provider may perform some of these tasks under delegation, but a regulator, board or customer will still ask the organisation how it governed that delegation.

The practical control set should cover named administrator identities, phishing-resistant authentication, just-in-time and least-privilege access, emergency accounts, segregation of duties, access reviews, logging, join-move-leave controls, customer approval for exceptional privileges and rapid revocation at termination. Machine identities deserve the same attention: service principals, integration accounts, certificates and automation credentials can survive staff and contracts.

Incident governance must also cross the seam. The agreement should define when InTWO notifies the customer, what facts it provides, who preserves evidence, how Microsoft and subcontractors are engaged, who performs regulatory assessments and how lessons modify service. Public search found no sufficiently verified timeline of service outages or security incidents specific to InTWO to analyse. That absence cannot support a claim of "clean record": private managed service incidents are often not publicly disclosed, and search visibility is not an assurance control.

The right security conclusion is neither alarm nor trust by logo. InTWO presents a plausible assurance framework and offers a report to customers. A buyer should verify that the report and operational evidence reach the exact legal entity, staff, locations, tools and cloud responsibilities in its proposed service. Assurance stops where the scope stops.

The Invoice Has Multiple Clocks

Neither SaaSplaza's earlier subscription model nor InTWO's current integrated service implies a single simple cloud price.

InTWO states that its Azure work is bespoke and that migration costs depend on the environment. It does not publish a standard managed services price list. Its Dynamics page claims potential cost reduction, but the method, sample, time horizon or customer distribution are not public. The responsible interpretation is that the economic case must be built customer by customer.

At least six cost streams may evolve on different clocks:

1. Microsoft Dynamics licences, often tied to user types, applications and contract terms.
2. Azure consumption for interfaces, analytics, virtual machines, storage, network traffic, security and recovery.
3. Commitments such as reservations or savings plans that trade flexibility for lower unit rates.
4. InTWO's recurring fees for monitoring, support, governance and included operational work.
5. Project or change fees for migration, extensions, hotfixes, testing and major releases.
6. Third-party products and services, including industry extensions, integration tools, backup components and other support contracts.

Microsoft'sAzure pricing pagemakes the underlying consumption and commitment choices visible, but a cloud solutions provider arrangement may change who receives the invoice, who sees native cost data and who administers commercial changes. A customer needs both a total invoice and access to the quantities underneath. Otherwise, the provider can claim savings without revealing whether they come from lower usage, longer commitment, reduced resilience, licence changes or a shifted baseline.

Managed service fees should be tested against scope and outcomes. Are they fixed per tenant, user, module, ticket volume, Azure spend or service tier? What is included in routine patching, release assessment, regression work and minor changes? Are out-of-hours interventions included? Does a Microsoft-caused incident consume customer hours? Are cloud provider credits passed through? What happens to reserved commitments on exit? Can the provider add margin on marketplace or Azure consumption, and if so how is it disclosed?

This is not an argument for pure time and materials. Predictable recurring pricing can align incentives if scope and service measures are clear. A percentage of cloud spend is not automatically bad either; it can fund tooling and optimisation. But it can also reward consumption. A buyer should establish a baseline, demand native cost visibility, define savings calculations, separate one-off transition costs from steady-state costs, and make resilience decisions explicit.

Internal costs do not disappear when operations are outsourced. The customer still needs process owners, vendor management, architecture authority, security oversight, acceptance testers and enough technical competence to challenge a diagnosis. Cutting these roles to make the economic case work can create a governance deficit that later appears as lock-in.

The most meaningful economic metric is cost per reliable business outcome over time: a close on time, a shipment released, a payroll completed, an update succeeded, an environment restored. It should include customer labour, provider fees, Microsoft charges, change projects and outage impact. That makes the coordination value of an integrated operator visible without pretending the invoice is simple.

Switching Costs Accumulate in Invisible Places

Microsoft may own the platform, the customer may legally own its data, and the tenant may be branded in the customer's name. None of these facts guarantees a low-cost operator switch.

Switching cost accumulates in knowledge: why a scheduled job starts at a particular time, which interface can be safely replayed, which extension breaks after a release, which leader can accept a close delay, which alert is noisy and which precedes a serious failure. It accumulates in tools: dashboards, scripts, deployment pipelines, test automation and ticket history. It accumulates in commerce: cloud subscriptions, reservations, marketplace products and support entitlements. It accumulates in access: provider-owned tenants, service principals, certificates and privileged roles.

It accumulates in relationships: named Microsoft escalation contacts and third-party providers accustomed to one operating model.

Some of these dependencies are productive. A provider should learn the customer deeply. Lock-in becomes harmful when the learning and artefacts cannot be transferred, when the architecture is unnecessarily tied to the provider's custody, or when the customer cannot measure the cost before termination.

Microsoft'sguidance on transferring Azure subscriptions involving a cloud solutions providershows why exit is more than a billing address change. It warns that billing and usage information is not transferred and must be exported first; marketplace software may need separate handling; a directory association change can affect role assignments and policies; some resources cannot be moved; and downtime may occur. The exact consequences depend on the exit agreement and tenant structure, but the official guidance refutes the notion of frictionless portability.

Dynamics has its own distinction between data and system. The Finance and Operations Data Management API provides supported data package paths, but exporting records is not the same as reproducing a configured ERP. In Power Platform, Microsoft recommends source control for exported unmanaged solutions and notes thatmanaged solutions and the default solution cannot simply be exported as unmanaged solutions. Dataverse's native backup documentation states that offline database backup download is not supported. These platform rules do not prevent exit; they mean exit must be designed with the correct artefacts rather than promised as "your data is yours."

A customer should negotiate an exit dossier at entry. It should include:

• tenant, subscription and billing ownership diagrams;
• current architecture and dependency maps;
• data dictionaries, extraction procedures and reconciliation controls;
• customer-owned repositories for custom code, deployment definitions and test automation;
• solution files and a register of components that cannot be exported in the preferred form;
• interface specifications, certificates, service identities and renewal dates;
• monitoring configuration, event and service level history;
• tickets, problems, changes and recovery records in a usable format;
• Microsoft and third-party contractual and support dependencies;
• reservation, marketplace, licence and credit schedules;
• a current privileged access register and revocation plan;
• runbooks, known error records and a structured knowledge transfer schedule;
• fixed transition assistance, rates, milestones and non-obstruction obligations.

The dossier should be tested before termination. A small annual exercise could export a chosen data set, rebuild a non-production integration from customer-controlled materials, remove and restore a delegated role, produce the last year's incident history and show how a replacement provider would receive the Microsoft support context. The goal is not to repeat a full migration every year. It is to detect custody and documentation gaps while the relationship is healthy.

European customers have an additional legal context. The European Commission states that theEuropean Data Actapplies from 12 September 2025 and includes a framework aimed at facilitating switching between data processing services. This may strengthen contractual expectations about cloud switching, but it does not automatically rebuild undocumented customisations, erase technical incompatibilities or identify the correct entity in a multi-party service. Customers should obtain legal advice on their own position and continue building technical exit.

Observable delegation again offers the best compromise. Customer-owned tenants and repositories, revocable management rights, portable evidence and explicit commercial schedules do not prevent InTWO from delivering a highly customised service. They make that service replaceable enough that renewal can be based on performance rather than fear.

Alternatives Test the Operating Model

InTWO does not only compete with another company selling an identical bundle. It competes with several ways to divide the work.

A large customer may keep a Dynamics centre of excellence, operate Azure in-house and buy Microsoft support directly. It gains control and institutional knowledge but must fund ongoing specialist coverage. It may split implementation, application support and infrastructure across different providers, gaining checks and balances at the cost of handoffs. It may use Microsoft's SaaS layer with minimal custom infrastructure and keep only specialised application support. It may hire another Microsoft-centred managed partner to cover much of the same stack.

The last category is demonstrably active. HSO currently marketsmanaged operations covering Dynamics 365, Power Platform, data and Azure, including release management, testing and business process monitoring. Columbus offersapplication managementwith incident and problem management around Dynamics 365. These are vendor descriptions, not a comparative performance study, and they do not prove equivalence in every region or module. They establish that InTWO's integrated Microsoft operational surface is contestable.

The meaningful comparison is therefore not company size or badge count. It is the shape of accountability proposed. Which bidder will own the application as well as the infrastructure? Which can support the customer's older Dynamics estate through transition? Which has functional experts for material business processes? Which offers dedicated team rather than shared queue? Which can work within customer-owned control planes? Which exposes its automation and evidence? Which accepts recovery and exit tests? Which legal entity serves each region, and where are privileged operations performed?

InTWO may have an advantage where SaaSplaza's historical knowledge, global Dynamics hosting experience and Azure operations genuinely reduce handoffs. A rival may have greater industry implementation depth, broader local staff, a clearer application management model or better commercial separation. An internal team may be best for a highly differentiated process with adequate scale. Multi-sourcing may be rational where concentration risk exceeds coordination benefit.

No reliable public market share data was found for this exact service boundary, and vendor-published customer counts are not comparable without definitions. Procurement should run a scenario-based evaluation: give each option the same release problem, failing integration, recovery and exit, then score authority, evidence, time, cost and residual customer labour. That tests continuity rather than marketing vocabulary.

Twelve Tests Before Handover

The following tests turn the control bargain into observable evidence. They are not a universal tender template; they are the questions most directly implicated by SaaSplaza/InTWO's public operational claims and Microsoft's platform rules.

1. Prove the contractual chain.Ask for the full legal name, registration, jurisdiction and address of the contracting entity; the entities performing the work; relevant parent guarantee; insurance; Microsoft partner and reseller roles; data processing parties; and the liability path. Reconcile these documents with the proposal. The historical record of SaaSplaza Inc. and the current InTWO brand should be linked by documents, not assumptions.

2. Draw the control map.For each tenant, subscription, environment, repository, vault, monitoring platform and support portal, record the owner, administrator, delegated roles, approval rights, log access and removal method. Mark assets that remain usable without InTWO. Require least-privilege design and test emergency revocation.

3. Demonstrate a broken business process.Use a controlled scenario relevant to the customer—a blocked shipment, a failed bank file or a duplicate interface message. Observe monitoring, triage, severity, cross-provider escalation, safe recovery and reconciliation. Measure process restoration, not ticket acknowledgment.

4. Contract the three clocks.Define response, restoration and resolution separately. Tie each to business impact, coverage hours, measurement points, exclusions, communications, credits and rights for chronic failure. Ask InTWO to calculate the consequences of its proposed availability definition using the customer's actual service hours and dependencies.

5. Run the next Microsoft update before signing.Select a representative release. Require a customer-specific impact assessment, automated and manual regression evidence, extension review, approval path, deployment record and rollback or mitigation plan. Confirm who pays to fix customer code affected by the cadence.

6. Inventory the integration estate.Record each interface, owner, data class, identifier, certificate, endpoint, schedule, retry rule, control total, vendor and recovery sequence. Require monitoring capable of distinguishing technical availability from complete and correct processing. Place specifications and executable materials under customer control.

7. Read the assurance file, not the badge.Obtain the current SOC report and any other claimed certification or assessment. Verify entities, systems, locations, period, exceptions, subcontractors and complementary customer controls. Add evidence of penetration testing, vulnerability management, privileged access and incident notification appropriate to the risk.

8. Rehearse recovery.Agree process-level recovery point and recovery time objectives. Restore in a safe environment, reconnect dependencies, validate access and reconcile data. Record actual elapsed time, manual steps, Microsoft dependencies and corrective work. Repeat after a material architecture change.

9. Rebuild the price.Separate Microsoft licences, Azure quantities, commitments, marketplace products, managed service inclusions, projects and third-party costs. Give the customer native usage and billing evidence. Model growth, contraction, a major incident, a major update, recovery and termination—not just the first steady-state year.

10. Rehearse a narrow exit.Export cost and incident history, remove a delegated role, transfer a non-production component, extract a reconciled data set and rebuild a chosen integration from customer-held artefacts. Identify anything that still requires proprietary tooling or an individual engineer, then price and close the gap.

11. Test the staff model.Meet the actual service manager, the Dynamics functional lead, the Azure lead, the security contact and the out-of-hours team. Ask what is dedicated, pooled, offshore, subcontracted and subject to turnover. Verify how customer context reaches a night engineer and how knowledge leaves with departing staff.

12. Call references by scenario.Seek customers with comparable modules, geography, integration density and regulatory requirements. Ask about a failed update, a Microsoft escalation, recovery evidence, billing transparency and a contested change. The Kingfisher announcement shows a relationship exists; a confidential reference should establish how the operating model performs.

These tests also clarify the retained duties of the customer. It must provide process owners, timely decisions, representative test data, identity governance, architecture authority and honest forecasts. A managed service provider cannot restore a process whose owner is unknown nor validate a financial outcome the customer has not defined.

The evaluation should output four connected documents: a responsibility matrix, a service level schedule, an operational evidence specification and an exit plan. If they contradict each other, the commercial scope is not ready to become a production responsibility.

What Public Evidence Cannot Settle

Continuity evidence is stronger than current contractual performance evidence.

RIB's audited reports prove the exact US SaaSplaza Inc. and describe the acquired service. Multiple 2021 reports and InTWO's own subsequent language prove the operating brand combination. The current leader biography connects SaaSplaza Americas management to InTWO in San Diego. The current service pages describe an extensive Dynamics and Azure operational offering. Microsoft documentation independently establishes the platform constraints within which that offering must operate.

The public sources do not settle several consequential questions:

• current registration status and exact role of SaaSplaza Inc. within today's group;
• which InTWO legal entity contracts in each country and which entities access customer systems;
• the scope, exceptions and latest results of the SOC 1 Type II examination;
• standard response, restoration and resolution targets or actual achievement;
• customer-specific recovery objectives and test results;
• the architecture and ownership model used for tenants, subscriptions and management tooling;
• current subcontractor, staff and privileged operations locations;
• a standard pricing structure or verified cost outcome distribution;
• volume, cause and resolution of security or availability incidents;
• retention, renewal, change and transition assistance performance;
• independent metrics behind the customer, availability and cost claims.

These gaps are not unusual for a privately delivered managed service. Contracts, audit reports and architecture records are often confidential. But confidentiality changes the venue of evidence; it does not eliminate the need for evidence. A serious buyer should receive the documentation under appropriate protections and retain enough derivative evidence for governance.

The distinction between claim and verification should remain visible. InTWO claims 24/7 coverage, broad operational responsibility, annual assurance, hundreds of customers, 99% application availability and potential cost reduction. The public record verifies that the commercial lineage and the offered service are plausible. It does not independently verify these performance outcomes across the customer base. The analysis therefore neither discounts nor elevates the claims to fact.

There is one more unresolved tension. Integration is InTWO's advantage and concentration risk. The more responsibilities a provider can coordinate, the fewer handoffs during an incident. The same provider can also become architect, operator, reseller, reporter and gatekeeper of exit knowledge. Only the customer's access to evidence and control keeps these roles aligned.

Watch the Control Boundary, Not the Logo

Several developments merit ongoing observation.

First,legal identity. InTWO should make its current group and regional contracting structure easy for professional buyers to reconcile. Any change of parent company, operating company, delivery site or Microsoft commercial role should trigger a review of liability, data processing, insurance, audit scope and exit.

Second,Microsoft's management plane. The 2026 transfer of update administration to the Power Platform admin centre shows that operational tools change even when the application brand does not. The spread of Power Platform automation, copilots and autonomous functions will add service identities, data paths, model governance and new failure modes. InTWO's automation should be judged by documented control and recoverability, not novelty.

Third,release and extension debt. Customers coming from older AX, NAV or GP estates may carry custom behaviour that becomes progressively harder to reconcile with cloud cadence. Monitor the share of exceptions, manual regression effort, obsolete interfaces and updates requiring project work. These are leading indicators of cost and lock-in.

Fourth,commercial custody. Track who owns Azure subscriptions, reservations, marketplace products, cost history and support entitlements. Microsoft's transfer rules can change, and the customer's architecture can drift. An exit plan tested at signing can become false after two years of new services.

Fifth,assurance scope. An annual report can remain current while service grows beyond the examined system. New locations, subcontractors, acquisitions, privileged tools and AI-assisted operations should be mapped into the audit boundary and customer controls.

Sixth,outcome measurement. InTWO's public claim of 99% application availability is too coarse to describe an ERP operation. Buyers should watch process-level service metrics, transparent restoration data, reduction in repeated incidents, release escape rates, recovery performance and verified cost baselines. Better metrics would be evidence that the company has evolved from hosting availability to operational continuity.

The name SaaSplaza matters because it anchors a specific story: an Amsterdam-based Dynamics cloud specialist with a real US company and a San Diego operation, acquired by RIB and absorbed into InTWO. That story supports experience. It does not settle today's contract, architecture or performance. The name InTWO matters because it is the current promise of a broader integrated Microsoft service. It does not erase the need to identify which entity and team stand behind the promise.

At 2 A.M., no customer benefits from debating brand lineage while orders wait. It benefits from a provider who can see the whole failure, has the authority to act, knows who to call, restores the process and leaves an audit trail. By day, however, governance must ask how that outcome was achieved, what it cost, what control the customer retained and whether another qualified team could take over.

That is the migration bargain. SaaSplaza/InTWO can reduce the friction of running Dynamics across Microsoft's cloud layers, updates and integrations. The customer should pay for that coordination when it is demonstrably better than alternatives. It should not trade away the evidence, ownership and exit rights that make coordination accountable. The final ledger is not the logo on the helpdesk. It is who can change the system, who bears the consequence, who can prove what happened and who can still operate when the relationship ends.