Migration · Assessment & readiness
Know what you’re moving
before you move it.
Office Unbound’s planned migration assessment tools will help organizations inventory their existing Microsoft 365 or Google Workspace environment, identify compatibility concerns, estimate migration requirements, and build a practical transition plan before transferring data.
Project status The Migration Assessment & Readiness Engine is planned for Phase 5A. Its architecture, permission model and report specifications are being defined in Phase 1, the current phase. Nothing on this page can be run yet.
What the assessment is for
A plan, an inventory and a list of decisions — not a transfer.
Most migration problems are visible before the migration starts, if anyone looks. A shared mailbox that thirty people rely on but nobody owns. A SharePoint library with broken permission inheritance three folders down. A Google Sheet whose formulas call functions no other spreadsheet application implements. A user with an alias that collides with someone else’s address at the destination. Found during the transfer, each of these is an incident. Found during an assessment, each is a line in a plan.
The Migration Assessment & Readiness Engine is the planned first stage of every Office Unbound migration. It connects to a customer’s existing Microsoft 365 or Google Workspace environment, reads what is there, compares it with what the destination can represent, and produces a written account of what moving would involve: what is supported, what needs conversion, what cannot move, what it will cost in time and infrastructure, and what has to be decided first.
It does not copy data. Its output is a set of reports and a proposed plan, and the step from assessment to migration requires an administrator’s explicit approval.
Ten assessment areas
What the engine is being designed to examine and report on, for both Microsoft 365 and Google Workspace sources. All planned.
Organization inventory
Users, groups, domains, mailboxes, calendars, contacts, storage and the supported collaboration workloads in the tenant — including shared mailboxes, resource calendars, Shared Drives and SharePoint sites that do not belong to any one person and are easy to overlook.
Data analysis
Mailbox sizes, message counts, file counts, total storage, shared content, large files and estimated transfer volumes, broken down per user and per workload so the heavy cases are visible rather than averaged away.
Compatibility analysis
Which features, file formats, permissions and integrations are supported, partially supported or unsupported at the destination. Partial support is described specifically: what survives, what changes and what is dropped.
Identity mapping
A proposed mapping of users, groups, aliases and permissions to the Office Unbound environment, with conflicts, duplicates, orphaned accounts and external identities flagged for a decision.
Migration estimates
Transfer time, bandwidth, destination storage, infrastructure requirements and potential costs — each stating the assumptions it rests on and how uncertain it is. More on this below.
Risk assessment
Potential data loss, unsupported workloads, API limitations, required source-side licensing, access issues and operational dependencies, such as line-of-business systems that send mail through the source tenant.
Readiness scoring
A migration-readiness summary that separates blocking issues from recommendations, with an action for each, so the result tells the reader what to do next rather than how to feel.
Migration planning
Recommended phases and waves, coexistence options, cutover requirements, the DNS changes involved, verification procedures and recovery strategies, derived from what the inventory actually found.
Exportable reports
PDF reports for IT staff, management and MSP customers, and CSV exports of the underlying per-user and per-item data for the people doing the work.
Approval gates
Explicit administrator approval before proceeding from assessment to migration, recorded in the audit trail against the version of the assessment that was approved.
Where it sits in the roadmap
Assessment is designed first and delivered before the transfer tooling, because the transfer depends on everything the assessment learns.
| Phase | What it covers | Status |
|---|---|---|
| Phase 1 — Architecture & planning | The migration discovery architecture, source API requirements, permission models, the compatibility matrix, the assessment methodology and the report specifications. Design work, not software. | Current phase |
| Phase 5A — Assessment engine | The guided tool described on this page: connect with authorized, least-privilege access and produce the ten-area assessment, reports and approval gate. | Planned |
| Phase 5B — Migration execution | Connectors and orchestration for Exchange Online, OneDrive, SharePoint, Gmail, Calendar, Drive and Docs; supported collaboration data; incremental transfers; scheduling and retries; progress monitoring; validation; completion reports; cutover and recovery procedures. | Planned |
The order matters. The compatibility matrix defined in Phase 1 is what the assessment checks against, and what the assessment records — identities, mappings, decisions, the approved plan — is what the execution tooling in 5B is intended to consume. A transfer that has to rediscover the tenant for itself is a transfer that can disagree with the plan that was approved.
Phase 5 depends on the destination services existing, so its place in the roadmap follows the core services. Migration design and prototypes may begin earlier. No dates are published for any phase; the roadmap explains why.
Authorized, least-privilege access
The assessment needs to see a great deal. It should be able to change nothing.
The engine is intended to connect through each provider’s own administrative authorization model. For Microsoft 365, that means an application registration consented to by a tenant administrator and calling Microsoft Graph. For Google Workspace, it means a super administrator authorizing access through the Admin console, typically by delegating specific API scopes to a service account. In both cases the administrator sees exactly which permissions are requested before granting them.
The design rule is to request read-oriented permissions only, and only for the workloads being assessed. An organization assessing mail alone should not be asked to grant access to files. Much of the assessment is meant to work from metadata — sizes, counts, folder trees, permission entries, file types — rather than from message bodies or document contents.
Tokens and credentials are to be stored encrypted, scoped to the one customer project, and revocable from the source side at any time. When an assessment is closed without proceeding, the report is intended to remind the administrator to remove the consent, and say where.
Some provider permissions are broader than an assessment needs. A read permission for mail, granted at the application level, can cover every mailbox in the tenant. Where a provider offers ways to narrow that — restricting an application to particular mailboxes, for instance — the tooling should support them; where it does not, the report should state plainly what access was granted and for how long.
Estimates that show their working
An estimate without its assumptions is a guess presented as a fact. Each figure the assessment produces is intended to carry the inputs behind it and what would change it.
| Estimate | Built from | Main sources of uncertainty | Status |
|---|---|---|---|
| Transfer time | Measured volumes and item counts per workload, the planned batch structure, and transfer rates observed during a sample or pilot. | Source-side API throttling, which the provider varies and does not guarantee; the mix of many small items versus few large ones; how busy the tenant is during the window. | Planned |
| Bandwidth | Total volume, the planned transfer windows and the destination’s network connection. | Whether the bottleneck is the network or the source API; other traffic on the same link. | Planned |
| Destination storage | Source volumes adjusted for version history kept, converted formats, and the destination’s storage layout. | Source-reported sizes are not destination sizes; conversion and retained versions can change totals in either direction. | Planned |
| Infrastructure | User counts, workloads selected and storage estimate, set against documented sizing guidance for the chosen components. | The components are still under evaluation, so sizing guidance does not exist yet; usage patterns differ by organization. | Planned |
| Potential costs | Infrastructure and storage estimates, the transfer duration, and rates the customer or MSP enters for their own hosting, labor and any overlap in source licensing. | Office Unbound does not know anyone’s prices; the figure is only as good as the rates supplied, and is shown as a range. | Planned |
Estimates are intended as ranges with the assumptions listed beside them, and to be revised after the pilot, when real transfer rates replace sampled ones. The assessment will not quote a single completion date, and this site does not quote typical durations or throughput, because no migration has yet been run with Office Unbound tooling.
Readiness, not a grade
The readiness summary is meant to answer one question — can this migration proceed, and if not, what is in the way? — rather than award a score out of a hundred. Findings are sorted into two kinds.
Blocking issues must be resolved or explicitly accepted before migration can be approved: a domain that cannot be verified at the destination, a workload the organization depends on that has no supported path, an identity collision with no resolution.
Recommendations improve the result without stopping it: clean up inactive accounts before mapping, archive a mailbox that is mostly old newsletters, review external sharing links before they are re-created.
Every finding is intended to carry a specific action and an owner, so the summary can be worked through as a checklist.
Approval gates
The assessment ends at an explicit approval: an administrator with the right role confirms they have reviewed the findings and authorizes the move to migration. The approval is recorded against the specific version of the assessment, so the audit trail shows what was known at the time.
- Approval is a deliberate action, never a default or a timeout.
- Accepted blocking issues are listed by name in the approval record.
- A stale assessment — one taken before significant change in the source — is intended to prompt a fresh inventory before approval.
- For MSP projects, the provider and the customer can each be required to approve.
Later gates in the migration process — before cutover and before decommissioning — follow the same pattern.
The report, in outline
Planned Conceptual outline only. No report has been produced, and there is nothing to screenshot.
The PDF report is intended for people who need to make a decision; the CSV exports for the people who will carry it out. A conceptual outline of the PDF:
- 1. Summary
- The source, the scope assessed, the readiness conclusion and the blocking issues, on one page for management.
- 2. Inventory
- Users, groups, domains and workloads found, with counts and storage totals.
- 3. Compatibility
- Supported, partial and unsupported items by workload, with what each partial item loses or changes.
- 4. Identity mapping
- The proposed mapping, and every conflict or ambiguity that needs a decision.
- 5. Estimates
- Time, bandwidth, storage, infrastructure and cost ranges, with assumptions and uncertainty.
- 6. Risks
- Each risk, its likely effect, and a mitigation or an explicit acceptance.
- 7. Proposed plan
- Phases and waves, coexistence approach, cutover and DNS changes, verification and recovery procedures.
- 8. Approvals
- Who approved, when, against which assessment version, with accepted issues.
CSV exports are intended to include per-user mailbox and drive totals, per-item compatibility findings, the identity mapping table and the list of items needing manual handling.
Assessments across a customer base
For MSPs, the assessment engine is intended to be the start of a sales conversation as much as a technical tool — and to keep every customer’s data separate while doing it.
Separate assessments
One assessment per customer, each with its own authorization against that customer’s own tenant.
Compare complexity
See across the portfolio which customers are straightforward and which carry blocking issues or unusual workloads.
Customer-facing reports
Reports written for the customer’s management, presented under the MSP’s own relationship with them.
Plan resources
Use estimates from several assessments to schedule technicians and infrastructure across projects.
Central tracking is intended to show status across projects without breaking tenant isolation: the MSP sees summaries and the projects its technicians are assigned to; one customer’s credentials, inventory and findings are never visible from another customer’s project. Tenant isolation is planned to be tested as part of the platform’s security verification rather than assumed. Office Unbound for MSPs
Want an assessment when it exists?
Register your interest and tell us your source platform and size. Organizations and MSPs who do will hear when the assessment engine reaches early testing.