OAC Technology’s cloud-migration pitch is more concrete than the average managed-service provider’s, but the company’s most consequential public assurance — that it is “SOC 2 compliant” — is not documented with the information a customer would need to assess its scope, age, or relevance to a Microsoft 365 deployment.
In an August 4 article, TechCabal presented the New Hope, Minnesota, managed IT provider as an example of a cloud-first MSP that names its core platforms rather than selling an undefined idea of “the cloud.” OAC’s own service pages support much of that narrower claim: the company explicitly offers migration assistance for Microsoft 365, OneDrive, SharePoint, Exchange Online, Azure, Google, and AWS, and separately markets support for Microsoft 365 applications.
For small businesses moving from Windows Server file shares, an aging Exchange deployment, or a mix of legacy Windows applications and cloud accounts, named platforms are useful. They establish that the provider is at least building around the systems customers actually run. But platform lists are the opening qualification for a migration partner, not proof that the difficult work — identity design, data validation, permission mapping, cutover planning, endpoint policy, recovery testing, and post-migration administration — is being performed to a defined standard.
OAC’s Microsoft 365 support page lists a broad range of Microsoft services, including Outlook, Teams, OneDrive, SharePoint, Power BI, Power Apps, Power Automate, Exchange Online, Azure, Windows as a Service, and Microsoft Copilot. Its cloud-migration page goes further, promising planning, minimal business interruption, training, and assistance moving email, files, data, and programs.
That is more useful than a generic MSP page that merely says it offers “cloud solutions.” OAC also has a stated business serving small and medium-sized organizations, including firms still operating legacy systems such as Novell NetWare, GroupWise, and older Windows and Windows Server releases. For customers with that kind of estate, a provider that recognizes legacy workloads exist is preferable to one that assumes every customer is beginning with a clean Microsoft 365 tenant.
Yet OAC does not publicly spell out which migration methods, tools, or acceptance criteria it uses. The distinction matters. Microsoft’s own documentation for IMAP migrations to Exchange Online warns that contacts, calendars, and tasks do not migrate through the basic IMAP path; it also identifies limits on message sizes and mailbox-item counts, and advises administrators to verify migrated data after each batch.
A Microsoft 365 move can look complete when mail is flowing and users can sign in, while still leaving behind delegated mailbox access, shared-drive structures, Teams configurations, archive policies, line-of-business integrations, or file permissions. Microsoft’s migration tooling helps, but the tooling does not eliminate design decisions. The MSP’s work is determining which data belongs where, deciding who should retain access, and proving that the destination is usable before the old systems are retired.
OAC says it can move “programs” to the cloud, but it does not publicly define what that covers. For a Windows shop, that phrase can mean anything from publishing an existing application through a hosted environment to refactoring a server-bound application, replacing it with SaaS, or simply hosting it on a virtual machine. Those are materially different projects with very different cost, downtime, licensing, security, and support implications.
OAC’s public cloud and Microsoft 365 pages name Microsoft products and several cloud destinations, but do not identify Huntress as a named security partner or AppRiver as an email-security platform. A search of OAC’s visible service material did not turn up a Huntress partner profile, a managed detection-and-response description, an AppRiver offering, or a technical stack page that would let a prospective client determine which service is included in which contract tier.
That does not establish that the relationships do not exist. MSP vendor relationships are often private, reseller-based, or described only in proposals and customer documentation. It does mean the specific Huntress and AppRiver assertions should be treated as TechCabal’s reporting until OAC provides a public technical description or contract-level confirmation.
The missing detail has practical consequences. “Managed security response” can describe a 24/7 human monitoring service with defined escalation procedures, or it can mean endpoint tooling that generates alerts for a local help desk during business hours. Those are not equivalent protections. Customers need to know whether OAC operates the response function itself, resells a monitored service, receives alerts from a third party, or provides only deployment and administration.
For Windows administrators, the questions should be operational: Does the service cover Windows endpoints, Windows Servers, Microsoft 365 identities, and cloud workloads? Is remediation included? Who has authority to isolate a device, disable an Entra ID account, or revoke sessions? Are after-hours actions automatic, approved in advance, or billed separately? OAC’s published marketing does not answer those questions.
The American Institute of CPAs describes SOC 2 in terms of reports issued after an independent CPA examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy. A SOC 2 report has scope: it identifies the service or system examined, the trust-services criteria involved, the period covered for a Type II report or point in time for a Type I report, the auditor, and the auditor’s opinion.
OAC does not publicly identify any of those elements. Its site does not say whether it holds a Type I or Type II report; name the CPA firm; give an audit period; disclose the systems in scope; specify which Trust Services Criteria were tested; or state whether customers can request the report under a nondisclosure agreement. No independently published report or auditor attribution surfaced in the available record.
That gap does not prove OAC lacks a SOC 2 report. SOC 2 reports are commonly restricted documents, and a company may reasonably require prospective customers to sign an NDA before sharing one. But the public claim, as currently written, is not independently checkable. For a buyer placing Microsoft 365 administration, remote-access tools, backup credentials, or privileged Windows endpoints in an MSP’s hands, “SOC 2 compliant” should prompt a document request, not end the due-diligence process.
There is a second issue in OAC’s own wording. Its cloud-migration page says it can tailor security to “meet or exceed” SOC 2, PCI, HIPAA, or NIST compliance. That is a service promise about a customer environment. It does not establish that OAC’s own managed-services operation has undergone a current SOC 2 examination. The two statements may both be true, but they refer to different things.
Before signing, a small business should require the migration statement of work to define the source systems, destination services, data classes, technical owner, cutover window, and rollback conditions. It should identify which Microsoft 365 licenses are being sold or managed, how administrative roles will be assigned, whether the customer retains break-glass accounts, and how Conditional Access, multifactor authentication, device compliance, BitLocker recovery keys, Exchange retention, and SharePoint external sharing will be configured.
The contract should also distinguish between a project and ongoing management. OAC’s public pages suggest it wants to provide both, but they do not state the support boundaries after cutover. A user unable to access an old shared folder, a finance application that still expects a local SQL Server, or a compromised Microsoft 365 account are not migration issues in the narrow sense. They are the incidents that determine whether the provider has actually assumed responsibility for the new environment.
OAC’s useful contribution is its willingness to name Microsoft 365, Exchange Online, OneDrive, SharePoint, Azure, Google, and AWS instead of relying only on cloud rhetoric. The reporting does not establish that the company has a uniquely advanced migration practice, nor does its public SOC 2 language establish the scope of its security controls. For prospective customers, the next step is concrete: ask OAC for the migration runbook, the security-service escalation model, and the current SOC 2 report details before granting it tenant-wide administrative access.
For small businesses moving from Windows Server file shares, an aging Exchange deployment, or a mix of legacy Windows applications and cloud accounts, named platforms are useful. They establish that the provider is at least building around the systems customers actually run. But platform lists are the opening qualification for a migration partner, not proof that the difficult work — identity design, data validation, permission mapping, cutover planning, endpoint policy, recovery testing, and post-migration administration — is being performed to a defined standard.
OAC’s Microsoft 365 coverage is real, but its delivery model remains thinly described
OAC’s Microsoft 365 support page lists a broad range of Microsoft services, including Outlook, Teams, OneDrive, SharePoint, Power BI, Power Apps, Power Automate, Exchange Online, Azure, Windows as a Service, and Microsoft Copilot. Its cloud-migration page goes further, promising planning, minimal business interruption, training, and assistance moving email, files, data, and programs.That is more useful than a generic MSP page that merely says it offers “cloud solutions.” OAC also has a stated business serving small and medium-sized organizations, including firms still operating legacy systems such as Novell NetWare, GroupWise, and older Windows and Windows Server releases. For customers with that kind of estate, a provider that recognizes legacy workloads exist is preferable to one that assumes every customer is beginning with a clean Microsoft 365 tenant.
Yet OAC does not publicly spell out which migration methods, tools, or acceptance criteria it uses. The distinction matters. Microsoft’s own documentation for IMAP migrations to Exchange Online warns that contacts, calendars, and tasks do not migrate through the basic IMAP path; it also identifies limits on message sizes and mailbox-item counts, and advises administrators to verify migrated data after each batch.
A Microsoft 365 move can look complete when mail is flowing and users can sign in, while still leaving behind delegated mailbox access, shared-drive structures, Teams configurations, archive policies, line-of-business integrations, or file permissions. Microsoft’s migration tooling helps, but the tooling does not eliminate design decisions. The MSP’s work is determining which data belongs where, deciding who should retain access, and proving that the destination is usable before the old systems are retired.
OAC says it can move “programs” to the cloud, but it does not publicly define what that covers. For a Windows shop, that phrase can mean anything from publishing an existing application through a hosted environment to refactoring a server-bound application, replacing it with SaaS, or simply hosting it on a virtual machine. Those are materially different projects with very different cost, downtime, licensing, security, and support implications.
The article’s Huntress and AppRiver references are not independently substantiated on OAC’s public site
TechCabal says OAC works with Microsoft 365, Exchange Online, AppRiver, and Huntress, framing the latter as part of its managed security response. The Microsoft platform claims are easy to corroborate on OAC’s own service pages. The Huntress and AppRiver details are more difficult to verify from OAC’s presently indexed public materials.OAC’s public cloud and Microsoft 365 pages name Microsoft products and several cloud destinations, but do not identify Huntress as a named security partner or AppRiver as an email-security platform. A search of OAC’s visible service material did not turn up a Huntress partner profile, a managed detection-and-response description, an AppRiver offering, or a technical stack page that would let a prospective client determine which service is included in which contract tier.
That does not establish that the relationships do not exist. MSP vendor relationships are often private, reseller-based, or described only in proposals and customer documentation. It does mean the specific Huntress and AppRiver assertions should be treated as TechCabal’s reporting until OAC provides a public technical description or contract-level confirmation.
The missing detail has practical consequences. “Managed security response” can describe a 24/7 human monitoring service with defined escalation procedures, or it can mean endpoint tooling that generates alerts for a local help desk during business hours. Those are not equivalent protections. Customers need to know whether OAC operates the response function itself, resells a monitored service, receives alerts from a third party, or provides only deployment and administration.
For Windows administrators, the questions should be operational: Does the service cover Windows endpoints, Windows Servers, Microsoft 365 identities, and cloud workloads? Is remediation included? Who has authority to isolate a device, disable an Entra ID account, or revoke sessions? Are after-hours actions automatic, approved in advance, or billed separately? OAC’s published marketing does not answer those questions.
“SOC 2 compliant” is not the same as a public, verifiable security attestation
The clearest discrepancy is OAC’s repeated use of the phrase “SOC 2 compliant.” It appears on the company’s services, about, resources, and cloud-migration pages, as well as in its footer. The phrase sounds definitive, but SOC 2 is not a certification program with a public registry, a universal badge, or one fixed set of controls.The American Institute of CPAs describes SOC 2 in terms of reports issued after an independent CPA examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy. A SOC 2 report has scope: it identifies the service or system examined, the trust-services criteria involved, the period covered for a Type II report or point in time for a Type I report, the auditor, and the auditor’s opinion.
OAC does not publicly identify any of those elements. Its site does not say whether it holds a Type I or Type II report; name the CPA firm; give an audit period; disclose the systems in scope; specify which Trust Services Criteria were tested; or state whether customers can request the report under a nondisclosure agreement. No independently published report or auditor attribution surfaced in the available record.
That gap does not prove OAC lacks a SOC 2 report. SOC 2 reports are commonly restricted documents, and a company may reasonably require prospective customers to sign an NDA before sharing one. But the public claim, as currently written, is not independently checkable. For a buyer placing Microsoft 365 administration, remote-access tools, backup credentials, or privileged Windows endpoints in an MSP’s hands, “SOC 2 compliant” should prompt a document request, not end the due-diligence process.
There is a second issue in OAC’s own wording. Its cloud-migration page says it can tailor security to “meet or exceed” SOC 2, PCI, HIPAA, or NIST compliance. That is a service promise about a customer environment. It does not establish that OAC’s own managed-services operation has undergone a current SOC 2 examination. The two statements may both be true, but they refer to different things.
A cloud migration needs a post-cutover operating plan
OAC is right to present migration as more than setting up accounts. Its public material recognizes the risks posed by legacy applications and advertises planning, minimal interruption, and training. Those are the right categories. What is absent is the measurable operating plan that converts them into a service customers can hold the provider to.Before signing, a small business should require the migration statement of work to define the source systems, destination services, data classes, technical owner, cutover window, and rollback conditions. It should identify which Microsoft 365 licenses are being sold or managed, how administrative roles will be assigned, whether the customer retains break-glass accounts, and how Conditional Access, multifactor authentication, device compliance, BitLocker recovery keys, Exchange retention, and SharePoint external sharing will be configured.
The contract should also distinguish between a project and ongoing management. OAC’s public pages suggest it wants to provide both, but they do not state the support boundaries after cutover. A user unable to access an old shared folder, a finance application that still expects a local SQL Server, or a compromised Microsoft 365 account are not migration issues in the narrow sense. They are the incidents that determine whether the provider has actually assumed responsibility for the new environment.
OAC’s useful contribution is its willingness to name Microsoft 365, Exchange Online, OneDrive, SharePoint, Azure, Google, and AWS instead of relying only on cloud rhetoric. The reporting does not establish that the company has a uniquely advanced migration practice, nor does its public SOC 2 language establish the scope of its security controls. For prospective customers, the next step is concrete: ask OAC for the migration runbook, the security-service escalation model, and the current SOC 2 report details before granting it tenant-wide administrative access.
References
- Primary source: TechCabal
Published: 2026-08-04T09:01:11+00:00
Loading…
techcabal.com - Related coverage: oactechnology.com
Loading…
www.oactechnology.com - Related coverage: oactechnology.com
Loading…
www.oactechnology.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com