Selected work

The problem.
The work.
The handover.

Four completed projects, each documented from the problem to the handover. Below them, prior experience and an illustrative example, kept separate and labelled as what they are.

First conversation free. Scope and price in writing before any access.

01 · Completed

Completed projects

Delivered work for clients of AZ Innovations: what was wrong, what was checked, and what each client kept.

Migrations · SharePoint

Finding the gaps after a file migration

Completed project · details anonymized

The problem
After a move to SharePoint, file differences and access issues needed investigation. Sync behavior and long project paths were part of the problem.
The work
Investigated sync and path problems, compared original and migrated files, and documented fixes and migration settings.

What was handed over

  • System guide. The migration setup and the fixes, written for the client’s team.
  • Comparison scripts. The scripts used to compare original and migrated files.
  • Check results. The validation reports from those comparisons.
  • Unresolved list. The exceptions that remained open at handover, listed as open.

Anonymized completed project. Some exceptions remained.

Original files compared with migrated filesFive original files are compared with their migrated copies. Four match. One fails because its path is too long, and it is added to the list of exceptions.File comparisonIllustrationORIGINALMIGRATEDPath too longAdded to the exceptions list
IllustrationConstructed file paths, not client files. One long path fails the comparison and is added to the exceptions list.
See a constructed sample of the handover
Inside the handover

Your system,
explained.

System guide · what this handover contained

  1. 01Migration setup
  2. 02File comparison scripts
  3. 03Check results
  4. 04Unresolved issues

Constructed file-check record · example paths only

01 Source
Projects / Sample project / Drawing register.pdf
02 Intended destination
SharePoint / Projects / Drawing register.pdf
03 Observed discrepancy
Transfer held: the source path needs an approved technical rename.
04 Recorded action · open
Owner to approve the rename and identify affected links. Retain the old/new path mapping and recheck transfer and access.
This constructed row is separate from the completed project described alongside it. No client files or paths are displayed.

Illustrative sample · constructed example

A path exception needs an action, not a green total.

Reconciliation excerpt · constructed project folder

Selected check

Has the path exception been corrected and the destination checked?

File transfer / exception recordIllustrative
File transfer / exception record: constructed inspection record
RecordEvidence or responsibilitySample review
Source itemProjects / Sample project / Drawing register.pdfPath exception open
DestinationSharePoint / Projects / Drawing register.pdfTransfer awaiting correction
AccessProject member allowed; unrelated pilot user denied.Test pending
Existing linksKeep the old-to-new path and links needing an update.Owner review required

This is one constructed item. No total migrated, success percentage or client file is represented.

Evidence
The source path needs an approved technical rename before transfer.
Decision
Keep the exception open
Next action
Owner approves the rename and identifies links that need updating.

Constructed row using the documented reconciliation method. It is not a recovered client file or an aggregate success rate.

About this work summary

Migration configuration notes, issue records, file comparison scripts and validation reports. Client names and identifying files are withheld.

Some exceptions remained in the reports. They do not show that every file was recovered or establish an overall recovery rate.

Devices · Windows setup

Finding why new laptops failed during setup

Completed project · details anonymized

The problem
New Windows laptops were failing partway through automated setup, but not every time. The firm was moving device management to the cloud and could not rely on a setup that sometimes stalled.
The work
Reviewed the deployment profiles, the setup status page, every application installed during setup, device policies, sign-in rules and group targeting. Then ran repeated wipe-and-setup tests on real hardware, captured the logs from each run and changed one factor at a time to isolate what the failed runs had in common.

What was handed over

  • Findings report. The causes the tests supported, each tied to the runs that showed it.
  • Test record. Every wipe-and-setup run: the scenario, the configuration, the result and the logs.
  • Change list. Configuration changes in priority order for the firm’s own team to apply.
  • Left with the firm. Rolling the changes out across every laptop stayed with their team.

Anonymized completed project. The investigation and its recommendations.

About this work summary

Scope and task breakdown, test-scenario definitions, per-run test records and the findings report. The client name and device details are withheld.

No failure rate, device count or before-and-after figure is published. The record covers the investigation and its recommendations, not the later fleet-wide rollout.

Files · Teams · AI readiness

Putting files, sharing and Teams in order before an AI assistant

Completed project · details anonymized

The problem
A consulting firm wanted to use an AI assistant across its files, but years of folders, broad sharing and inconsistent Teams settings meant nobody could say what the assistant would surface.
The work
Reported who could reach each site, corrected the agreed permissions, wrote and configured the data-loss-prevention plan and automatic labelling, moved the file structure from nested folders to described, searchable metadata, set group rules for onboarding and agreed how Teams meetings are recorded.

What was handed over

  • Readiness assessment. What an AI assistant could reach, with an action plan in order.
  • Permission reports. Who could reach each site, and the agreed corrections.
  • Data protection. The data-loss-prevention plan and automatic labelling, configured and written down.
  • Information structure. Files moved from nested folders to searchable metadata, with the reasoning behind each decision.
  • Outside the scope. Content beyond the agreed sites was not reviewed.

Anonymized completed project. Covers the agreed scope.

About this work summary

Statement of work and progress records, site permission reports, the data-loss-prevention plan, labelling and metadata documents and the readiness assessment. The client name and content are withheld.

No count of sites, files or corrected permissions is published. The record covers the agreed scope; it does not claim that all content in the firm was reviewed.

Email · delivered for a partner

Moving client mailboxes for an IT provider, under its name

Completed project · details anonymized

The problem
An IT provider needed mailbox moves done for several of its small-business clients and did not have the migration specialist on staff. The clients had to keep working, and the provider had to keep the relationship.
The work
Ran discovery for each client, agreed the scope in writing, backed up the existing mail, moved the mailboxes to Microsoft 365 and checked each one with the provider before handing it back.

What was handed over

  • Migrated mailboxes. Each one checked with the provider before it was handed back.
  • Backup of the old mail. Kept, so nothing depended on the move alone.
  • Migration note per client. Short enough for the provider’s own team to support from.

Anonymized completed project. Delivered under the provider’s name.

About this work summary

Per-client discovery notes, signed agreements, migration notes and invoices. The provider and its clients are not named.

No mailbox count or duration is published. The record describes the work categories delivered through one partner; it is not a statement about every client of that partner.

02 · Prior experience

Prior experience

Work our technical lead has delivered before AZ Innovations, summarized from privately reviewed contracts. Each summary shows the kind of problem handled; none claims a measured result.

Access investigation · Exchange

Email forensics: establishing what happened in a mailbox

Prior delivery experience · work summary

The problem
A prior engagement concerned an investigation into Exchange email activity.
The work
The reviewed contract record covers Exchange email-forensics work. Client logs, technical findings and investigative material are not published here.
What this shows
The reviewed contract supports prior experience in this work category. It does not establish a specific incident finding, technical outcome or regulatory conclusion.
About this work summary

Prior individual delivery experience, summarized from privately reviewed contract records. Names and original titles are withheld; these are not presented as contracts awarded to AZ Innovations.

The underlying contract record is not published here. This summary establishes work category only; no specific finding or audit outcome is claimed.

Application packaging · Intune

Application packaging for managed laptops

Prior delivery experience · work summary

The problem
A prior engagement required application packaging for managed Windows devices.
The work
The agreed work covered packaging specialist desktop applications for deployment through Intune.
What this shows
The reviewed contract supports prior application-packaging experience. It does not substantiate fleet-wide deployment figures, time savings or repeat hiring.
About this work summary

Prior individual delivery experience, summarized from privately reviewed contract records. Names and original titles are withheld; these are not presented as contracts awarded to AZ Innovations.

The underlying contract record is not published here. No device count, deployment speed or continuing client relationship is inferred.

Permissions and cost · Azure

Permissions and cost visibility in a cloud subscription

Prior delivery experience · work summary

The problem
A prior engagement concerned access permissions and cost visibility in Azure.
The work
The reviewed contract supports this category of Azure work. Client permissions and billing records are not published.
What this shows
The reviewed contract establishes prior experience in this work category; it does not establish savings or a measured technical outcome.
About this work summary

Prior individual delivery experience, summarized from privately reviewed contract records. Names and original titles are withheld; these are not presented as contracts awarded to AZ Innovations.

The underlying contract record is not published here. No cost reduction or access result is inferred from the contract category.

03 · Illustrative

An illustrative example

A representative provider-exit sequence that shows the approach. It is constructed and kept separate from completed projects.

GoDaddy exit

Leaving GoDaddy with a plan for access and email

Illustrative example · representative scope

Example situation
A business wants control of its Microsoft 365 administration and licenses when leaving its current provider.
Example approach
This representative sequence brings together ownership checks, the provider release, licensing, user communication, a pilot and sign-in and mail-flow validation. The actual sequence depends on the tenant and provider.
What it helps you plan
An agreed target for account control, a sequence for the change, and checks for sign-in and email. This is an illustrative approach, not a measured client result.

Constructed sequence. Not a measured client result.

See a constructed check from this sequence

Illustrative sample · constructed example

Change provider control while keeping the tenant in view.

Existing tenant · provider transition

Selected check

Can the authorized client administrator manage the existing tenant?

Provider exit / control transferIllustrative
CONTROL BOUNDARYExisting Microsoft 365 tenantUsers and mailboxes stay in this tenant.
ADMINISTRATIONClient administratorAuthorized access + recovery check
DOMAIN / DNSRegistrar account ownerAuthority must be established before DNS-dependent work
LICENSE / BILLINGClient + providerAgree replacement licenses and release sequence
APPROVALClient change ownerApprove scope, timing and remaining conditions

A provider release changes control. It is not a mailbox-data transfer.

Provider exit / control transfer: constructed inspection record
RecordEvidence or responsibilitySample review
Tenant identityConfirm the existing tenant is the intended destination.Existing tenant retained
Provider releaseAgree release timing and replacement license sequencing.Release pending
AdministrationVerify the authorized client administrator can manage it.Provider dependency
ContinuityCheck pilot sign-in, mail flow and billing ownership.Checks pending

Representative sequence. Provider timing remains external; a control change may not move mailbox data.

Evidence
Client sign-in depends on the current provider; release not confirmed.
Decision
Hold the transition
Next action
Confirm the release steps and license sequence before changing sign-in.

Representative example. Provider release times remain external dependencies. A defederation is not always a mailbox-data migration.

About this example

Representative scope and handover structure, informed by an anonymized engagement narrative.

Details are representative. Defederation and tenant migration are different paths; discovery determines which is appropriate.