Is Your App Ready for Azure? How to Catch Deployment Blockers Before They Cost You Time

The Problem: You've Built Your App, But Can It Actually Run on Azure?

You've spent weeks, maybe months, building an application. The code works locally. Your team is confident. You're ready to deploy to Azure and start serving users.

So you begin provisioning infrastructure — maybe writing Bicep templates, setting up Azure App Service, or configuring container registries. You run azd up or push to your CI/CD pipeline. And then... it fails.

Maybe the build breaks because a dependency isn't compatible with the runtime you selected. Maybe your app relies on a local service like a file-based database that doesn't exist in the cloud environment. Maybe you discover that the framework version you're using isn't supported by the Azure service you targeted. Or perhaps you realize halfway through that you need a Dockerfile, but nobody thought to create one.

These aren't hypothetical scenarios. They happen constantly in real-world deployments. The root cause is almost always the same: teams jump to infrastructure planning before validating that their source code is actually deployable.

Why This Happens

The gap between "code that works locally" and "code that deploys to a cloud platform" is wider than most developers expect. Here's why:

• Local environments are permissive. Your machine has global packages, environment variables, local databases, and filesystem access that cloud environments don't provide.
• Dependency assumptions are implicit. Your package.json or requirements.txt might list dependencies, but not whether those dependencies are compatible with the target runtime or architecture.
• Configuration is scattered. Connection strings, environment variables, and service bindings are often hardcoded or assumed to exist without being declared.
• Framework support varies. Azure supports many frameworks, but not every version of every framework on every service. A Node.js 14 app won't run on a service that requires Node.js 18+.
• Nobody checks until it's too late. The typical workflow goes: write code → write infrastructure → deploy → fail → debug. The failure happens at the most expensive stage.

What a Good Solution Should Change

A proper pre-deployment evaluation should happen before any infrastructure work begins. It should:

1. Scan the repository statically — without installing dependencies or running builds — to identify what the app contains.
2. Detect the tech stack — frameworks, languages, runtimes — and verify compatibility with Azure services.
3. Check build health — are there build scripts, manifest files, and configuration that indicate a buildable project?
4. Evaluate completeness — does the app have the files it needs to deploy (e.g., Dockerfile, entry points, configuration)?
5. Identify blockers — unsupported frameworks, incompatible dependencies, missing configuration, or reliance on local-only services.
6. Produce actionable verdicts — not just "pass/fail," but specific recommendations: what needs to change, what's missing, and what's blocking deployment.

The goal is to shift the failure point left — from the infrastructure deployment stage back to the code evaluation stage, where fixes are cheap and fast.

Introducing azure-app-onboard-prereq: A Pre-Deployment Code Readiness Check

One option for addressing this problem is the azure-app-onboard-prereq skill. It's designed to evaluate your source code repository for Azure deployment readiness before you write a single line of infrastructure code.

This skill is part of a larger AppOnboard pipeline from Microsoft's azure-skills repository, but it can also be used as a standalone tool. Its purpose is straightforward: scan your repo, assess what's there, and tell you whether your app is ready to deploy — and if not, what's blocking it.

What It Actually Does

The skill performs a multi-axis evaluation of your repository:

• Build Health Check: Does your project have the manifest files (e.g., package.json, pom.xml, go.mod, Cargo.toml) needed to build? Are build scripts defined? Is there a Dockerfile or equivalent?
• Completeness Check: Does the app have entry points, configuration files, and the minimum structure expected for a deployable application?
• Deployability Check: Are the detected frameworks and runtimes compatible with Azure services? Are there dependencies that would cause deployment failures? Are there local-only services (like SQLite file databases or localhost URLs) that won't work in the cloud?
• Dependency Compatibility: Are there known incompatibilities between your dependencies and the Azure target environment?

The output is a set of per-component verdicts — PASS, WARN, or FAIL — with specific explanations and recommended fixes.

A Critical Design Decision: Read-Only Evaluation

One important characteristic of this skill is that it is strictly read-only during evaluation. It does not install dependencies, run builds, or execute tests. This is a deliberate design choice:

• It keeps the evaluation fast and safe — you're not modifying your environment.
• It avoids the risk of side effects from running arbitrary build commands.
• It works on any repository without requiring a working local environment.

Instead, the skill performs static analysis: reading manifest files, checking for configuration patterns, detecting framework versions from dependency declarations, and comparing against known Azure compatibility data.

This means it can evaluate a repository even if you don't have the runtime installed locally. It also means it won't catch runtime errors — it's checking structural readiness, not functional correctness.

When This Skill Applies (And When It Doesn't)

Good Use Cases

• Before starting infrastructure work. You have a working app and want to know if it's ready for Azure before writing Bicep, Terraform, or ARM templates.
• Evaluating a new repository. You've inherited or forked a project and need to understand its deployment readiness.
• Pre-deployment audits. Your team wants a systematic check before a release to catch configuration gaps or dependency issues.
• Monorepo assessment. The skill can detect multiple components in a single repository and evaluate each independently.
• Answering "can I ship this to Azure?" A direct question that the skill is explicitly designed to answer.

When NOT to Use It

The skill's documentation is clear about its boundaries:

If you need to...	Use instead
Validate existing infrastructure code (Bicep, Terraform, azure.yaml)	azure-validate
Generate infrastructure-as-code	azure-prepare
Run a full end-to-end deployment pipeline	azure-app-onboard
Execute azd up or deploy to Azure	azure-deploy

This skill is specifically the first phase — the code readiness check. If you've already written infrastructure and need to validate it, this isn't the right tool.

What It Won't Do

• It won't fix your code. It identifies issues and recommends fixes, but remediation is a separate step (and a separate protocol within the pipeline).
• It won't run your tests. It checks for test configuration files statically, but doesn't execute test suites.
• It won't install packages. The evaluation is entirely static.
• It won't generate deployment configurations. It tells you what you need, but doesn't create it.

Evaluating Whether This Skill Fits Your Workflow

Setup Context

The skill operates within a session-based workflow. It creates a session directory (.copilot-azure/sessions/{session-id}/) and writes evaluation artifacts there. It reads your repository structure and produces a prereq-output.json file with structured findings.

It can be invoked in two ways:

1. As part of the azure-app-onboard pipeline — where it runs as Step 3 of a larger onboarding flow.
2. Standalone — where you invoke it directly for a code readiness check.

If invoked standalone, it handles session creation automatically and checks for an active Azure account via az account show.

Safety Signals

• Read-only by default. The skill does not modify your code during evaluation. The only exception is a remediation phase that runs only if you have blocking issues, and even then, it requires explicit user consent before making changes.
• No arbitrary command execution. The skill has an explicit prohibition against running npm install, pip install, dotnet build, pytest, or any other install/build/test command during the prereq phase. This is enforced as an absolute rule in the skill's configuration.
• User consent gates. Any code modifications require user confirmation. The skill limits itself to a maximum of 3 questions before presenting results.
• MIT licensed. The underlying repository uses a permissive open-source license.

Repository Signals

The skill comes from the microsoft/azure-skills repository:

• 1,328 stars and 220 forks — indicating meaningful community adoption.
• Maintained by Microsoft — the same organization that maintains Azure itself, which means the compatibility data and best practices are likely to be current.
• Part of a structured pipeline — the skill is one phase in a 4-phase AppOnboard pipeline, suggesting it's been designed with a clear scope and integration points.
• Low security level — the skill performs static analysis and doesn't require elevated permissions or access to external services beyond Azure CLI for account verification.

Things to Inspect Before Using

Before adopting this skill, consider:

1. Your tech stack. The skill detects common frameworks and languages, but check whether your specific stack is covered. The evaluation references Azure best practices via mcp_azure_mcp_get_azure_bestpractices, which validates detected patterns.
2. Monorepo complexity. If your repository has many components, the skill can handle it, but the component mapping logic may need review for your specific structure.
3. Cloud SDK dependencies. If your app uses AWS SDK, Google Cloud SDK, or Firebase, the skill will flag this early and offer to redirect you to a cloud migration skill. Be aware of this behavior if you're evaluating a multi-cloud application.
4. Integration with your CI/CD. The skill produces structured JSON output (prereq-output.json) that can be consumed by downstream tools, but you'll need to wire it into your pipeline if you want automated pre-deployment checks.
5. Remediation expectations. The skill identifies issues but follows a separate remediation protocol for fixes. If you're expecting automatic fixes, understand that this requires additional steps and user consent.

Practical Example: What the Evaluation Looks Like

Imagine you have a Node.js Express application with the following structure:

my-app/
├── package.json
├── src/
│   └── index.js
├── .env
└── data/
    └── local.db

The skill would likely produce findings like:

• PASS: package.json exists with valid dependencies and a start script.
• WARN: .env file detected — environment variables need to be configured in Azure App Settings or Key Vault.
• FAIL: data/local.db indicates a local SQLite database — this won't persist in Azure App Service. You need to migrate to Azure SQL, Cosmos DB, or another managed database service.
• WARN: No Dockerfile detected — if you plan to use container-based deployment, you'll need to create one.
• PASS: Node.js version in engines field is compatible with Azure App Service supported runtimes.

These verdicts give you a clear picture of what needs to change before you invest time in infrastructure.

Summary

The gap between "works locally" and "deploys to Azure" is a common source of wasted time and frustration. The azure-app-onboard-prereq skill offers a structured, read-only evaluation of your repository to identify deployment blockers before you start infrastructure work.

It's not a universal solution — it's specifically designed for the pre-deployment code readiness phase. It won't validate infrastructure, generate deployment configs, or fix your code automatically. But if you're at the stage where you're asking "is my app ready for Azure?" or "what's blocking my deployment?", it provides a systematic way to answer those questions.

Evaluate it against your specific tech stack, understand its read-only design, and check whether its output format integrates with your workflow before adopting it.