What I learned preparing for Cloud Migration and Modernization of Microsoft

Cloud partner audits can look simple from the outside. You receive a checklist, find some projects, collect evidence, join the audit call, and hope to pass. Reality, is much more different. These audits are not only about having good cloud engineers or successful projects. They are about proving, with clear evidence, that your organization has a repeatable capability.

A company can deliver a very good migration project and still struggle during an audit. Not because the delivery was bad, but because the evidence is missing, hard to find, or not mapped to the audit requirements.

The auditor needs proof. The real question is not only whether we did the work. The real question is whether we can prove that we did the required activity, for a real customer, with clear and verifiable evidence.

Start with candidate projects, not all projects

In a large organization, it is not realistic to track every cloud migration and modernization project for audit purposes. There are too many projects, regions, delivery models, client constraints, and documentation habits.

A better approach is to create an audit-candidate pipeline. A few months before the audit, identify possible projects, shortlist the strongest ones, and build evidence packs only for those. In my view, it is better to start with several possible projects, select two or three strong candidates, and keep one backup.

Pre-assessment is the most important step

For each candidate project, the pre-assessment must validate two things.

·       Does the project really satisfy the audit requirement?

·       Does the evidence exist to prove it?

Many times, teams stop at the first question. They say, “Yes, we did this.” But for the audit, this is only half of the answer. You need to know where the document is, whether it is customer-specific, whether it is from the right period, whether it can be opened during the audit, and who can explain it.

Be careful with T&M and staff augmentation projects

T&M and staff augmentation projects can be very good customer references. They show trust. They show that the customer values your people. They can be useful for relationship proof and commercial credibility. But they are not always good audit candidates.

If your role was only to provide one or two engineers, the customer may still own the assessment, architecture, migration plan, governance, testing, documentation, and final decisions. Your people may have contributed a lot, but the evidence may not show that your organization delivered the full capability required by the audit. The auditor is asking - Can your organization prove this capability with objective evidence?

For me, the rule is simple: T&M and staff augmentation projects are good customer badges, but they are not automatically good audit evidence.

A folder is not an evidence pack

Another lesson is that a folder full of files is not enough. You need an evidence matrix. The matrix should map each audit requirement to the project, evidence link, owner, status, gap, and next action. The important part is to split complex requirements into smaller parts.

For example, “workload assessment” may look like one requirement, but in reality it may include workload inventory, dependencies, risks, business context, constraints, migration approach, and target architecture assumptions.

If this is kept as one line, it is easy to think it is done. But during the audit, the auditor may ask for one specific detail and you may discover that the evidence is weak. It also makes the audit discussion easier, because you can navigate directly to the evidence.

Infrastructure and managed cloud components matter

Not every good audit project needs to be a pure application modernization project.

Cloud migration and modernization audits often include landing zones, networking, identity, governance, monitoring, operations, security, managed services, and transition to support.

Because of this, infrastructure-heavy projects should not be rejected too quickly. A project with managed cloud components can be a strong audit candidate, especially if it includes clear evidence for governance, monitoring, operations, and cloud platform readiness.

The question should not be, “Is this only an application project?” The better question is, “Does this project provide enough evidence for migration, modernization, managed services, governance, monitoring, and operations?”

A repeatable migration approach helps

I do not believe every project should be tracked only for audit. That is too heavy. But I strongly believe a company needs a repeatable cloud migration and modernization approach.

This approach should define the typical team shape, key activities, roles and responsibilities, expected outcomes, and examples of evidence. Not every project will be identical, and that is fine. But the organization needs a common language and a common way of explaining how migration and modernization are delivered.

This helps during audits because you are not only showing one good project. You are showing that the company has a repeatable way of working.

What worked well for me

Looking back, the things that helped most were simple:

• Having multiple candidate projects reduced the risk. If one project had missing evidence or did not fully match the requirement, there were other options.
• Having named technical owners was critical. Documents are useful, but someone must explain what was done, why decisions were made, and how the evidence proves the requirement.
• Using an evidence matrix helped a lot. Without it, people lose time searching folders and discussing documents that are not clearly connected to the audit requirement.
• Running checkpoints created discipline. It gave us moments to review progress, identify gaps, and decide what needed more work.
• Keeping a backup project gave us more confidence and reduced the risk of depending on only one customer example.
• Looking at infrastructure and managed cloud components helped us not reject useful projects too early.
• Run as a project. Define milestones, tasks, and clear ownership of each phase.

What I would do better next time

Next time, I would improve a few things:

• Make the pre-assessment stricter from the beginning.
• Validate earlier if the project is eligible, if it is within the required period, and if it includes migration or modernization scope.
• Confirm earlier if our organization had meaningful delivery ownership, not only staff augmentation involvement.
• Check from the start if the evidence already exists and can be shown during the audit.
• Be more careful with staff augmentation projects. They may be excellent customer references, but they can be weak audit examples if they do not show ownership and clear deliverables.
• Split complex requirements in the evidence matrix earlier. This avoids discovering too late that one big requirement is only partially covered.
• Confirm backup SMEs, not only primary technical owners.
• Run a mock audit before the real audit.

Final thought

My biggest lesson: Good cloud delivery is not the same as good audit evidence.

You can have strong engineers, successful projects, and happy customers. But for an audit, you need to demonstrate capability in a structured, evidence-based way.  Select the projects carefully based on the work delivery to that customer, the project complexity and type and not on the customer's logo.