Vianordis
--:--:-- UTCVianordis / SUPPORT
migration

O365 Migrator

Available

O365 Migrator helps administrators move users, mail, calendars, contacts, and tasks from Microsoft 365 into GoSec Cloud services. It supports staged runs, incremental synchronization, progress tracking, and validation before cutover.

Verified user manual

O365 Migrator operator manual

Plan, dry-run, execute, validate, and audit Microsoft 365 migrations into approved GoSec Cloud target services.

Manual
Version 1.0
Product
O365 Migrator source release 3577f03
Verified
July 15, 2026
Language
English · Source
Owner
Migration platform and support
Source
o365Migrator · 3577f03
Review cycle
90 days
Start here

Audience, scope, and prerequisites

Covers controlled use of the authenticated migration service for email, calendars, contacts, tasks, and other enabled workloads. It does not document Kubernetes deployment, database administration, LDAP provisioning commands, or secret management.

Who this is for

  • Authorized migration operators
  • Tenant administrators coordinating a migration
  • Support and compliance reviewers

Before you sign in

  • An approved migration plan, maintenance window, owner, and rollback/escalation decision
  • Provisioned target users and required mail, calendar, contact, and tenant attributes
  • Validated Microsoft Graph and target-service credentials held outside the support workflow
  • A source inventory, user mapping, workload selection, and acceptance criteria
Access model

Roles and responsibilities

RoleAccessResponsibilities
Migration operatorCreate, monitor, stop, and validate authorized jobs through the protected management API or approved operator interface.
  • Use dry-run first
  • Limit user and workload scope
  • Preserve job evidence
Tenant administratorApprove source-to-target identity mappings and service readiness.
  • Ensure users and quotas exist
  • Coordinate user communications and cutover
ReviewerReview inventory, progress, validation, and exception reports.
  • Confirm acceptance criteria
  • Escalate unexplained data loss or duplication
Workspace map

Navigation

Health and readiness

/health

Verify source and target dependency readiness through the approved interface.

Inventory

/inventory

Collect and compare source workload and user scope.

Jobs

/migrations

Create and review migration jobs.

Progress

/migrations/{job-id}

Monitor item counts, rate, errors, and job state.

Validation

/validate

Compare approved source and target scope after migration.

Chapter 01

Plan and assess the migration

A successful run begins with identity readiness, bounded workload scope, and measurable acceptance criteria.

Procedure 1.1

Prepare source and target scope

Define exactly which users, workloads, folders, and time boundaries are authorized.

  1. 1
    Approve the migration record

    Record business owner, operator, source tenant, target tenant, window, and escalation contacts.

  2. 2
    Map identities

    Create an explicit source-user to target-user mapping and resolve aliases or renamed accounts.

  3. 3
    Verify target provisioning

    Confirm each target user exists and the required mail, calendar, contact, and task services are enabled.

  4. 4
    Select workloads

    Choose only the approved data types and document known fidelity limitations.

  5. 5
    Define acceptance

    Set count, date-range, folder, calendar, contact, attachment, and exception thresholds.

Expected result

The migration has an approved, reproducible scope and every target identity is ready before source data is read.

Procedure 1.2

Collect and review inventory

Use inventory data to estimate work and detect unsupported or unexpectedly large scope.

  1. 1
    Run dependency checks

    Confirm Microsoft Graph, authentication, target services, and required databases report ready.

  2. 2
    Collect source inventory

    Select the approved users and data types without starting migration.

  3. 3
    Review counts and size

    Compare folders, messages, events, contacts, tasks, attachments, and any enabled workloads.

  4. 4
    Resolve exceptions

    Investigate missing users, unsupported types, quota risks, and oversized content.

  5. 5
    Freeze the baseline

    Attach the sanitized inventory summary to the migration record.

Expected result

The operator has a baseline against which dry-run, migration, and final validation can be compared.

Chapter 02

Dry-run and execute

Use the same mappings and workload selection for dry-run and production; change only the explicitly approved execution mode.

Procedure 2.1

Run a dry-run

Simulate the selected migration without writing target content.

ForMigration operator
  1. 1
    Create a dry-run job

    Use the approved source users, target users, data types, and mode with dry_run enabled.

  2. 2
    Monitor to completion

    Watch discovered, eligible, skipped, and failed item counts.

  3. 3
    Review mapping output

    Check identities, folders, calendars, address books, and task lists.

  4. 4
    Resolve every blocking error

    Correct configuration or scope rather than accepting unexplained skips.

  5. 5
    Approve production readiness

    Record the dry-run job ID and reviewer decision.

Expected result

The dry-run completes without target writes and produces an accepted estimate and exception set.

Procedure 2.2

Execute the initial full migration

Create one controlled full job and monitor it without overlapping runs.

Before you begin

  • Accepted dry-run
  • Approved migration window
  • Target backup or recovery decision
  1. 1
    Reconfirm the window

    Notify stakeholders and confirm no conflicting migration job is active.

  2. 2
    Create the full job

    Reuse the approved mappings and workload selection with mode full and dry_run disabled.

  3. 3
    Record the job ID

    Attach it to the change or migration record before monitoring.

  4. 4
    Monitor progress

    Review migrated, skipped, failed, throughput, and estimated remaining values.

  5. 5
    Stop on a safety threshold

    Use the supported stop action if errors, incorrect mapping, duplication, or target impact exceed the approved threshold.

  6. 6
    Preserve final state

    Export or record the sanitized completion and error summary.

Expected result

The full job reaches an explicit terminal state with traceable counts and no unexplained overlapping execution.

Procedure 2.3

Execute an incremental synchronization

Migrate changes since the accepted full-run baseline using persisted sync state.

  1. 1
    Confirm the baseline

    Use the same user mappings and locate the accepted full or prior incremental job.

  2. 2
    Review source change window

    Confirm the incremental run covers the expected period before cutover.

  3. 3
    Create the incremental job

    Select mode incremental and the approved workloads.

  4. 4
    Monitor deltas and errors

    Compare changed-item counts with business activity during the interval.

  5. 5
    Record the cutover state

    Preserve completion time and any remaining exceptions before changing user routing or access.

Expected result

Changes since the baseline are processed and the final incremental state is ready for cutover validation.

Chapter 03

Validate and close

A completed job is not accepted until representative content, counts, permissions, and user access are verified.

Procedure 3.1

Validate migration results

Compare source and target data using counts plus representative item-level checks.

  1. 1
    Run supported validation

    Compare the approved source and target users and workloads.

  2. 2
    Review totals

    Explain differences among source, migrated, skipped, failed, and target counts.

  3. 3
    Sample content

    Check recent and older mail, folders, attachments, recurring calendar events, contacts, and tasks as applicable.

  4. 4
    Test user access

    Have authorized representatives sign in and verify required target services.

  5. 5
    Classify exceptions

    Separate accepted fidelity limits from defects requiring remediation.

  6. 6
    Approve or roll back

    Record the final decision, residual risks, and follow-up owner.

Expected result

The migration has a documented acceptance decision supported by counts, samples, user checks, and an exception register.

Operating rules

Security and data handling

  • Use least-privileged source and target credentials and never place them in job notes or tickets.
  • Restrict migration scope to explicitly approved users, workloads, and time ranges.
  • Use dry-run before every materially different production scope.
  • Protect inventories, mappings, logs, and validation reports as sensitive administrative data.
  • Stop and escalate on incorrect identity mapping, cross-tenant visibility, unexplained duplication, or data loss.
Current release

Known limitations

Read before relying on an unsupported workflow

These limits describe the source-pinned O365 Migrator source release 3577f03 scope and must be rechecked when the product changes.

  • Users must be provisioned in the target directory before migration.
  • Workload fidelity varies; Teams chat messages are export-only in the verified source and cannot be imported with full fidelity.
  • Dry-run estimates do not prove target capacity, final API behavior, or end-user acceptance.
  • Incremental mode depends on persisted sync state and must use the approved baseline and mappings.
  • The service is an operator tool; normal end users should not create or control jobs.
Problem solving

Troubleshooting

You cannot sign in to O365 Migrator

Likely cause: The session expired, the identity is not assigned to the application, or the tenant claim is missing.

  1. Open the application from the approved portal and complete sign-in again.
  2. Confirm that the correct organizational identity and tenant are selected.
  3. If access is still denied, record the time and request an entitlement check from support.

A documented action or navigation item is not visible

Likely cause: The current role, release, tenant configuration, or feature flag does not expose that operation.

  1. Confirm the role and prerequisites listed for the procedure.
  2. Reload the page after signing in again; do not attempt to bypass the interface through direct URLs.
  3. Ask the product owner whether the feature is enabled for the tenant before reporting a defect.

A saved change or background operation is not visible

Likely cause: Validation failed, processing is still running, or the current view is stale or filtered.

  1. Review inline validation, status indicators, filters, and the selected tenant or workspace.
  2. Refresh once and search for the item by its stable name or identifier.
  3. Do not repeat irreversible or externally visible actions until the original operation status is known.

A target user fails readiness or validation

Likely cause: The identity, tenant, service attribute, quota, or target authentication is missing or inconsistent.

  1. Stop the affected user scope.
  2. Compare the approved mapping with target directory and service attributes.
  3. Provision or correct the target, then repeat dry-run for that bounded scope.

A production job reports unexpected failures or duplicates

Likely cause: Mappings changed, a job overlaps, sync state is inconsistent, or target writes partially succeeded.

  1. Stop new jobs for the scope.
  2. Preserve job IDs, item counts, and sanitized errors.
  3. Determine the last confirmed source and target state before retrying or remediating.
Escalation

Contact support

Contact support when

  • A repeatable O365 Migrator error blocks an approved workflow
  • Expected data, permissions, or tenant boundaries appear incorrect
  • A security, privacy, compliance, or data-loss concern is suspected
  • A production job requires stopping or remediation
  • Source and target totals cannot be reconciled
  • A cutover decision is blocked

Include

  • The page, action, and expected result
  • The exact error text and time of occurrence, including time zone
  • Your tenant, role, browser, and a sanitized record or item identifier
  • Whether the problem can be reproduced and which troubleshooting steps were tried
  • Migration and dry-run job IDs
  • Approved user/workload scope and sanitized count summaries

Never include

  • Passwords, access tokens, API keys, recovery codes, or session cookies
  • Unredacted personal, health, financial, or other regulated data
  • Private encryption keys or complete confidential documents unless an approved channel is provided
Contact support