How should we handle deployments when an app works on dev IIS but not production?

Start with the actual failure rather than debating whether the servers are identical. Is the site returning an IIS error, failing at startup, or breaking only when it reaches the database?

Ask the production team for the relevant IIS logs, Windows event logs, and application logs around the failure. You can help interpret the errors and work through the next checks together. If the logs don't explain enough, add more targeted logging for the next deployment, taking care not to expose credentials or other sensitive data.

Write down what the app needs to run, then compare that with production. Check the IIS app pool identity, file permissions, installed runtimes and libraries, environment variables, connection strings, database access, and network or firewall rules.

Some differences are expected, especially identities and connection strings. The question is whether each environment has the right values and access, not whether every setting is literally identical. If production is inaccessible to you, the sysadmins will need to check those settings or share appropriate diagnostic details.

Look closely at the handoff. Copying the published folder might be enough for some apps, but it won't automatically install runtimes, configure IIS, set permissions, or provide environment-specific settings.

Make a repeatable deployment package or automated process that both teams use. Document prerequisites and configuration separately, including how production secrets are supplied. That gives you a known artifact and a clear record of what still has to be configured on the server.

A test environment between dev and production can catch this stuff before release. Set it up to match production's relevant IIS configuration, dependencies, and access controls, then deploy to it using the same process and package intended for production.

A rebuild recipe helps keep that environment useful. Dev servers tend to accumulate extra configuration, so a successful dev publish alone doesn't prove the package is complete.

Have the deployment or app check its prerequisites where practical. For example, a database connectivity check with a useful error can narrow down a failure much faster than a generic startup error. Keep the diagnostic detail in protected logs rather than displaying sensitive information to site visitors.