How we work
Before a migration, access change or infrastructure project, agree what is included, when to stop, how the result will be tested and who takes over.
First conversation free. Scope and price in writing before any access.
Delivered on Microsoft 365, Azure and the systems you already run.
You describe what needs to change, what must keep working and the deadline. We say whether it is our kind of work.
The proposal names who leads the work and what is in and out. The price is fixed in writing before we get access to anything.
Access is tested against real cases. Releases are checked against a list. Ownership is mapped so nothing is left with nobody.
What was agreed, what changed, what was tested and what remains open. Your system, explained.
Illustrative project record · no client data
Client
The client names the source share, destination and users who need access.
Constructed example of a file migration. A review produces recommendations; a separately agreed implementation changes the system. The client retains the unresolved exceptions as well as the checks.
Open the full illustrative cutover recordWhere the work begins
A plan is not an implementation. Each is agreed and priced on its own, so you always know which one you are buying.
When important dependencies are unknown
Review the design, connected systems, capacity needs and cost assumptions before committing to implementation.
An agreed price for a review that sets out the options, recommendations and reasons behind them.
When the target and dependencies are established
Make the agreed changes with access, responsibilities and work windows arranged in advance.
A written scope, fixed price, exclusions, completion checks and a System guide at handover.
The first scope conversation is free. A provider exit with known users and connected services may be quoted directly. A move involving several tenants, unknown archives and unresolved ownership may need separately priced planning first. Your team keeps that plan, including when another provider performs the delivery.
What you keep
Each stage of a project leaves a record your team keeps. Six stages, six things you can open after we have gone.
Business
What must the system make possible?
What you keepA project brief with measurable requirements and a named sponsor.
Data
What information must move, remain, and be protected?
What you keepA map of the data in scope, where it can live and the retention and recovery rules it must meet.
Platforms
Where should workloads run, and what must support them?
What you keepA proposed system design showing where applications run, capacity estimates and how failures are contained.
Identity
Who and what can act across the architecture?
What you keepA map of user, administrator and application access, including who approves changes.
Transition
How will change be controlled and the result demonstrated?
What you keepAn approved change plan and a record of the tests used to sign off on the result.
Operations
Who owns the result, its cost, and its continuing evidence?
What you keepOperating instructions, cost assumptions, test records and named support responsibilities.
Working responsibilities
Your sponsor approves the scope and spending. Your technical owner or project manager coordinates access, connected systems and test reviews. AZ Innovations is responsible for the technical work agreed in the proposal.
The proposal names scheduled work and change windows, response expectations, the client’s operating owner and any limited post-handover support. Evening or weekend work can be arranged subject to availability.
Access is requested in writing, restricted to the approved scope, protected with multifactor authentication and removed at handover.
New dependencies and scope changes are recorded with their effect on price, timing and acceptance. Affected work proceeds after approval.
Pilots, waves, change windows and rollback criteria are agreed before anything changes on the live system.
Your named owner receives the design decisions, test results, open issues, runbooks and confirmation that our access has been removed.
How you know the work is good
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we workRelease checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverablesA System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Tell us what is getting in the way and when you need it resolved. We explain the scope questions before you commit to paid work.
Discuss your projectFirst conversation free. Scope and price in writing before any access.
Before you commit
Start with the problem and the result you need. The first conversation is free and needs no access to your systems.
Review selected work and evidenceYour proposal names the technical lead responsible for the scope, the technical work and the handover. If a specialist collaborator is needed, their role is agreed with you before work starts. Responsibilities and the project calendar are written into the same proposal.
We agree the scope, fee and completion checks in writing. Access uses named accounts and only the permissions the work requires. Approved access is reviewed and removed at handover.
Your scope defines the pilot, test cases and acceptance checks. Results and exceptions are recorded. Recovery options and their limits are agreed before any change to the live system; a failed check is addressed before the next approved stage.
A defined project can end at handover. Your team receives the agreed configuration records, a System guide and a walkthrough. Any limited support period is written into the proposal; ongoing support or additional work is a separate agreement.
