Azure DevOps Classic to Dev Platform Migration FAQ

About This Document

This FAQ covers the most common questions encountered when migrating from the Mend Classic integration (repo-based, PAT/bot-user) to the Mend Developer Platform on Azure DevOps. Questions are ordered by frequency—the topics asked about most often appear first.

1. Overview & Why Migrate

Q1: What is the difference between Classic and Developer Platform for Azure DevOps?

Classic (Legacy): Uses a bot-user account with a Personal Access Token (PAT) that scans repositories. Configuration is managed via a .whitesource JSON file committed to your repo. Scanning happens at scheduled intervals or via webhook triggers. Projects, products, and tokens are managed manually.

Developer Platform (New): Uses OAuth-based authentication. Configuration is managed through the Mend UI (no .whitesource file needed). Provides native SAST scanning within the repo (not just pipeline), PR decoration with security checks, Renovate dependency updates, and secret detection—all configured from a single dashboard.

Q2: Is Classic being deprecated? Do we need to migrate now?

Classic is not formally deprecated yet, but Mend has confirmed a gradual deprecation plan. Critically, Microsoft is deprecating global-scoped Personal Access Tokens (PATs) in Azure DevOps, which the Classic integration relies on:

• March 15, 2026 – Creation of new global PATs and regeneration of existing global PATs will be blocked.

• December 1, 2026 – All existing global PATs will be fully decommissioned and will stop working.

Since the Mend Classic Azure DevOps integration relies on global PATs, December 1, 2026 is the effective hard deadline for completing your migration to the Developer Platform. If you have not yet migrated, we recommend extending your existing global PAT's expiration date—or creating a new one with a long expiration—prior to March 15, 2026. This will give you sufficient time to complete the transition.

Migrating now also unlocks features only available on the Developer Platform (SAST in repo, secret scanning, UI-based configuration).

Q3: What new capabilities does the Developer Platform provide over Classic?

Note: Many core features (PR security checks, Renovate integration, secret detection, Azure DevOps work item creation) are available in both Classic and Developer Platform. The following are genuinely new or significantly improved in Developer Platform:

• SAST as a first-class citizen: Static analysis runs natively in the repo integration, not just in CI/CD pipelines. Classic required a separate CLI-based pipeline approach for SAST.

• UI-based configuration: Eliminates the need for .whitesource JSON files. Everything is managed through the Mend UI, including global settings, branch rules, severity thresholds, and scan types.

• Monorepo partitioning: Improved support for monorepo setups with UI-based path partitioning.

• Unified dashboard: Single pane of glass for SCA, SAST, Secrets, and Renovate configuration per repository, versus the split management approach in Classic.

2. Pre-Migration Planning

Q4: Can we run Classic and Developer Platform side by side during the transition?

Yes, with a key constraint: You can run both integrations within the same Azure DevOps organization, but not on the same project simultaneously. The approach is:

• Remove the Classic bot-user from the specific project(s) you want to migrate.

• Onboard only those projects to the Developer Platform.

• Leave remaining projects on Classic until you're ready to migrate them.

You can also create a separate Mend organization for testing the Developer Platform before cutting over production projects. This allows you to validate the integration without risking your existing setup.

Q5: What should we inventory before starting the migration?

The most common migration blockers stem from gaps in pre-migration planning. Document the following before starting:

• Number of Azure DevOps organizations: Some enterprises have multiple AZDO instances (e.g., legacy vs. enterprise/SSO). Each requires separate planning.

• Number of projects per org: Plan which projects migrate first—starting with lower-risk projects is recommended.

• Monorepo vs. multi-repo: If you have monorepo structures, you'll need to plan partitioning mapping. The Developer Platform handles monorepos better than Classic, but you need to understand the layout first.

• Current .whitesource configurations: Map all existing JSON configs—global, repo-level, and project-level. These will be replaced by UI settings.

• Pipeline SAST integrations: If you run CLI-based SAST scans in your pipeline (e.g., at PR gates or in offline mode), these may need to be reconsidered for the repo-based SAST approach. Note: SCA pipeline scans (Unified Agent) are unaffected by this migration.

• Downstream integrations: If you feed Mend data to an ASPM or other tools via API, verify the structure of the Applications/Projects before cutover.

• Service accounts and permissions: You may need to create a dedicated service user for the integration. Document who has admin access.

Q6: How long does the migration typically take?

Timelines vary significantly by complexity:

3. Installation & Setup

Q7: What permissions are needed to install the Developer Platform?

Initial installation requires Azure DevOps admin access (Project Collection Administrator or Organization owner). After installation, the day-to-day operation requires a dedicated user or service account with the following permissions:

• Read/write access to repositories (for scanning)

• Create/update commit statuses (for PR checks)

• Create/update pull requests (for Renovate)

• Create/update work items (for issue creation)

Mend also offers a "Delegated Org Admin" feature where an admin can authorize a non-admin user to manage the Mend integration. Once installed, the dedicated user needs specific repo permissions, not admin.

Q8: How do I uninstall Classic before installing Developer Platform on a project?

Follow these steps:

• Step 1: In Mend UI, go to the Classic integration settings. Remove the bot-user from the specific Azure DevOps project you want to migrate. Do NOT remove it from the entire org if other projects still use Classic.

• Step 2: Delete the .whitesource configuration file(s) from the project's repos. (The Developer Platform doesn't use them, and leaving them can cause confusion.)

• Step 3: In the Mend Developer Platform, install the AZDO integration and select only the project(s) you removed from Classic.

• Step 4: Verify scans run successfully on the migrated project before proceeding with additional projects.

⚠️ Important: Developer Platform can only be uninstalled by the onboarding user

The Developer Platform can only be removed from AZDO automatically by deleting the account that initiated the onboarding (Login to Developer Platform → Account Settings). If you disconnect an organization and later connect another, all settings will remain in place and Renovate will stay installed. It is recommended to use a service user to install the Developer Platform to avoid issues in the future. If you need to uninstall the Developer Platform and do not have access to the original account, disconnect the organization in the Mend Developer Platform settings then clean up any orphaned webhooks in AZDO (Project Settings > Service hooks). Plan your initial setup carefully to avoid this scenario.

Q9: What happens to our existing scan data and history when we migrate?

Historical data remains in the Classic Mend organization. The Developer Platform creates a new project structure (Organization > Application > Repository). Your old findings don't automatically transfer. Plan for this by:

• Exporting reports from Classic before cutover (PDF or API export)

• Running initial full scans on the Developer Platform to establish a new baseline

• Accepting that there will be a brief "noisy" period as the new scans report known findings as new

If you use an ASPM or downstream tool that consumes Mend API data, consider running both integrations in parallel temporarily and validating that the Developer Platform API output matches your tool's expectations.

4. Configuration & Settings

Q10: How do I configure branch scanning? Can I scan branches without reporting them to the Mend UI?

This is one of the most frequently asked questions. A common enterprise pattern is: "We want to scan feature branches at PR time to catch issues, but only report findings from the main/release branch to the Mend UI."

The Developer Platform supports several branch scanning modes:

• Default (base) branch: Always scanned and reported to the Mend UI. This is the primary branch (e.g., main, master) configured as the base branch for the repository.

• Release branches: Can be explicitly added to scan and report for SCA (dependency) scanning. Important: Release branch scanning is NOT available for SAST—SAST only scans the default branch and PR diffs.

• Feature branches: To enable scanning of feature branch commits, go to Settings > Dependencies > Scan all Feature Branches. This enables SCA scanning on all feature branches, not just the default branch. Note: Feature branch commits scanned this way will not upload to the Mend UI.

• Pull Request scans: PRs are always scanned automatically—this is not a separate setting. PR scans check for new vulnerabilities introduced in the PR diff.

Note: This branch scanning setup is similar to Classic. The main difference is that configuration is done through the Mend UI rather than .whitesource files, and SAST scanning adds a new dimension that is Developer Platform-specific.

Q11: How does configuration work without the .whitesource JSON file?

In Classic, you may have a hierarchy of configs: a main .whitesource file with global settings, plus project-level overrides. The Developer Platform replaces this entirely with UI-based configuration:

• Global (project-level) settings: Applied at the project level and inherited by all repositories in that project.

• Repository-level overrides: Available per-repo. Important nuance: If you do NOT set a repo-level override, changes to the global project settings will automatically apply to that repo. However, once you create a repo-level override for a setting, global changes to that setting will no longer cascade to that repo. This means overridden repos must be updated individually.

There is no need for .whitesource files. All configuration—severity thresholds, scan types (SCA, SAST, Secrets), branch rules, PR checks, and work item creation—is managed through the Mend UI.

Q12: How do we handle monorepo setups with the Developer Platform?

Monorepo support is significantly improved in the Developer Platform via Monorepo Partitioning. If your repo contains multiple logical applications, you can define application boundaries within a single repo.

Configure partitioning in the Developer Platform: navigate to the specific Repository > Settings > General > Monorepo mapping. Define path patterns for each logical application within the repo (e.g., /app1/**, /app2/**).

Q13: How do we set up Azure DevOps work items (Issues/Bugs) from Mend findings?

Azure DevOps work item creation is available in both Classic and Developer Platform for SCA findings. With the Developer Platform's native SAST integration, SAST findings can also trigger AZDO work items directly—eliminating the need for intermediate ticketing workarounds (e.g., routing through Jira) for SAST-specific findings.

In the Developer Platform, work item configuration is spread across multiple settings sections (not a single "Issue Tracker" page):

• General: Base work item settings and integration connection

• Dependencies: SCA-related work item creation rules and severity thresholds

• Dependency Licensing: License violation work item creation

• Code Security: SAST finding work item creation

Area path configuration per-repo is available for routing work items to specific teams.

5. Authentication & OAuth

Q14: What authentication does the Developer Platform use?

The Developer Platform uses OAuth 2.0 authentication instead of Personal Access Tokens (PATs). During installation, you authorize the Mend app in your Azure DevOps organization, and it creates an OAuth connection. This is more secure than PATs because:

• OAuth tokens are scoped to specific permissions

• No PAT rotation required (a common Classic maintenance burden)

• Tokens are managed by the Mend platform, not by individual users

Q15: Microsoft is deprecating OAuth for Azure DevOps. How does this affect us?

This is a critical upcoming change. Microsoft is deprecating OAuth 1.0 (the current authentication method) for Azure DevOps and moving to Entra ID (formerly Azure AD) authentication.

Mend is actively working on Entra ID support. The expected timeline is end of Q1 2026. If you're migrating now, this should not block you—the current OAuth will continue working until Microsoft's deprecation date, and Mend will update the integration before that deadline. However, it's worth noting in your migration plan.

Q16: We had OAuth token expiration issues. Is this expected?

There is a known issue where the AZDO Developer Platform integration's refresh token can expire, causing scans to stop working silently.

Workaround: If you see scans suddenly stop with no error, check the integration status in the Mend UI. If the OAuth connection shows as disconnected, re-authorize the integration. Mend engineering has a fix in progress for the refresh token handling.

6. Common Migration Issues & Troubleshooting

Q17: Will enabling the Developer Platform flood us with new issues?

This depends on your current Classic scanning coverage:

• If Classic was scanning the same repos: You'll see findings re-reported as "new" in the Developer Platform, but the actual vulnerability count should be similar. The initial scan will appear noisy.

• If Classic was scanning fewer repos: Yes, you'll see new findings for any repos not previously scanned.

Best practice: Enable on 2–3 representative repos first, review the findings volume, then expand.

Q18: We need a service user (not a personal account) for the integration. How?

Several customers require this for compliance and audit reasons. The approach is:

• Create a dedicated Azure DevOps service account (e.g., mend-service@yourorg.com)

• Grant it the required permissions (repo access, commit statuses, PR access, work items)

• Perform the Developer Platform OAuth installation while logged in as this service account

• This ensures the integration isn't tied to any individual's personal Azure DevOps account

Tip: Create the service user first, then install. If you install under a personal account and later want to transfer to a service user, you'll need to re-authorize the integration.

Q19: Scans are stuck or failing after migration. What should we check?

The most common post-migration issues are:

• 1. Orphaned webhooks from Classic: If Classic wasn't fully uninstalled before Developer Platform was set up, duplicate webhooks can cause conflicts. Check Azure DevOps project settings > Service hooks for any stale Mend/WhiteSource hooks and remove them.

• 2. OAuth token expired: Check the Mend Developer Platform > Integrations page. If the AZDO connection shows disconnected, re-authorize it (see Q16).

• 3. Database configuration (EU instances): Customers on Mend's EU environment may hit database configuration issues that cause scans to get stuck. This requires Mend support to investigate server-side.

• 4. Permission changes: If the service account's AZDO permissions were modified (e.g., during an org-wide security review), scans will fail silently. Verify the dedicated user still has required access.

7. Common Migration Scenarios

Q20: We want to migrate one project at a time (phased rollout)

This is the most common approach. Remove the bot-user from one project, install the Developer Platform on that project only, and leave the remaining projects on Classic. This is fully supported.

Key tip: Start with a less critical project to validate the setup, then migrate high-value projects once you're confident.

Q21: We have multiple Azure DevOps organizations

Each Azure DevOps organization can be installed and managed in the same installation if the installation user has access to each org. If you have multiple AZDO instances (e.g., legacy vs. enterprise/SSO), map out which repos live in which org.

Key tip: If consolidation of AZDO orgs is planned, it may be better to consolidate first, then migrate to the Developer Platform on the unified org.

Q22: We're migrating FROM Azure DevOps TO another SCM (e.g., GitHub)

If you're changing source code management platforms entirely, uninstall the AZDO Developer Platform integration, then install the Developer Platform integration for your new SCM. Historical data doesn't transfer between SCM integrations.

Q23: We use AZDO for CI/CD but GitHub (or another SCM) for source code

Install the Developer Platform separately for each SCM. The Mend organization can span multiple SCM integrations—repositories from different SCMs will appear in the same Mend org.

Q24: We need area path mapping for AZDO work items

Area path routing is available in the Developer Platform's work item configuration settings. Each repo can be mapped to a different area path, allowing you to route findings to the appropriate team automatically.

8. Known Limitations & Workarounds

Q25: What limitations should we know about before starting?

9. Quick Reference: Step-by-Step Migration Checklist

Phase 1: Planning

1. Inventory AZDO organizations, projects, and repos

2. Document all .whitesource configuration files and their settings

3. Identify monorepo structures (if any)

4. Verify admin access availability for installation

5. Create a dedicated service account for the integration

6. Export current scan reports from Classic for baseline comparison

7. Check downstream integrations (ASPM, ticketing, dashboards)

8. Extend your existing global PAT expiration date before March 15, 2026 (or create a new long-lived PAT) to ensure Classic continues operating during the transition

Phase 2: Pilot Migration (1–2 projects)

9. Remove Classic bot-user from pilot project(s)

10. Delete .whitesource files from pilot repos

11. Install Developer Platform integration (as service user)

12. Configure scan settings in Mend UI (branches, SAST, SCA, Secrets)

13. Run initial scans and validate findings against Classic baseline

14. Configure PR checks and work item creation

15. Validate downstream integrations (API data matches expectations)

Phase 3: Rollout

16. Migrate remaining projects in batches

17. Clean up orphaned webhooks after each batch

18. Verify branch scanning rules per project

19. Remove Classic integration entirely once all projects are migrated

Phase 4: Post-Migration

20. Monitor OAuth token status (watch for expiration—see Q16)

21. Review and tune severity thresholds and PR check policies

22. Set up Renovate for dependency updates (if applicable)

23. Plan for Entra ID transition when Mend releases support

24. Note: repo-level setting overrides do not inherit global changes (see Q11)

25. Ensure full migration is complete before December 1, 2026 (global PAT decommission date)