Architecture & trust

Separate migration content from vendor control services.

ALZA is designed with a customer-hosted data plane for migration execution and a separate cloud control plane for licensing and operational metering. This reduces third-party content exposure without misrepresenting the risks that remain in Microsoft APIs, networks, endpoints, or customer configuration.

Customer-controlled execution boundary

Migration content moves directly through your environment.

The local ALZA Engine handles the source-to-target data path, while the separate ALZA cloud control plane is limited to licensing, entitlement, usage metering, and operational health signals.

Customer-controlled perimeter architecture: Microsoft 365 source tenant transfers through the customer-hosted ALZA Engine to the Microsoft 365 target tenant. The separate ALZA cloud control plane handles license validation, entitlement, usage metering, and operational health signals, with no customer migration content staging.
Customer-hosted migration data plane with a separate ALZA licensing and operational control plane.

Customer-hosted data plane

Workers run on customer-managed Windows infrastructure and move content between authorized Microsoft 365 tenants.

Separated ALZA control plane

ALZA cloud services validate licensing and usage; they are not designed to stage or relay customer migration content.

Locally controlled authorization

Tenant credentials and authorization tokens are handled by the local deployment under customer access controls.

Scale-out workers

Add internal worker virtual machines for parallel capacity while remaining inside approved network boundaries.

Service-aware execution

Observe service pressure, retries, and throughput while scaling within Microsoft service limits.

Auditable release

Publish a signed installer with checksum, version, requirements, data-flow documentation, and release notes.

Before product launch

Evidence the release.

  • Supported operating systems and prerequisites
  • Code-signing publisher identity
  • SHA-256 checksum and file size
  • Permissions and data-flow documentation
  • Logging, retention, and deletion behavior
  • Versioned release notes and support route
Before customer migration

Evidence the plan.

  • Agreed source and destination scope
  • Identity and workload ownership
  • Readiness and exception criteria
  • Cutover and communications plan
  • Rollback and escalation decisions
  • Validation and acceptance criteria
Next step

Review your security and migration assumptions with ALZA.

Tell us the workloads, user count, and target date. We’ll help you define a realistic evaluation path.

Chat on WhatsApp