Microsoft Prebid Adapter Migration: Publisher Checklist

Microsoft Prebid Adapter Migration should be on every affected publisher’s technical roadmap before early 2027. Microsoft says the legacy AppNexus adapter will shut down, be removed from Prebid.js and lose its legacy endpoint. Waiting until the final release window creates unnecessary revenue and consent risk.

The replacement is not a simple bidder-name edit. The Microsoft adapter uses the bidder code msft, changes some parameters and targeting values, uses standardised first-party-data locations and requires a newer native implementation. A safe migration needs inventory mapping, configuration updates, controlled testing and a rollback plan.

Why publishers need to act now

Microsoft’s latest Monetize update says the AppNexus adapter will shut down in early 2027. It advises publishers to move to the Microsoft Prebid Adapter and update Prebid.js so consent information can pass correctly, particularly where DV360 demand is involved.

A broken migration can reduce eligible bids, damage reporting or interrupt native and video demand. The effect may look like normal market volatility if the team does not record a clean baseline. Publishers should complete the change before a peak period and allow time for buyers, ad-server targeting and consent flows to stabilise.

What changes between the adapters

The official Microsoft bidder documentation explains that the new adapter connects to Microsoft’s exchange using OpenRTB 2.5 and supports banner, video and native formats. It also documents migration differences that must be reviewed rather than copied blindly from the old configuration.

1. Build an implementation inventory

List every site, app, Prebid bundle, wrapper, ad server and deployment path that includes AppNexus. Record the Prebid.js version, adapter modules, placement IDs, media types, timeouts, floors, consent framework and responsible owner. Include test environments, regional builds and vendor-managed wrappers.

Search source code and tag-manager configurations for appnexus, legacy endpoints and bidder-specific targeting keys. Do not assume one central wrapper controls every property. Old microsites or direct publisher integrations can remain hidden until traffic drops.

2. Capture a clean revenue and delivery baseline

Before changing production, save at least several comparable weeks of bid requests, response rate, timeout rate, win rate, CPM, revenue, fill, latency and discrepancies. Segment by domain, placement, device, format and major demand path. Annotate promotions, outages and seasonality.

Use the baseline to find material regressions, not to promise identical auction outcomes. Kayaar’s measurement stack guide explains why operational reporting, causal tests and business planning should not be treated as one interchangeable answer.

3. Update code, parameters and targeting together

Build a new Prebid.js package with the Microsoft adapter and required modules. Replace the bidder code and map each parameter according to current documentation. For example, the placement field changes from camel case to placement_id, which accepts an integer.

Then inspect ad-server line items and key-value targeting. Rules matching hb_bidder=appnexus or AppNexus-specific price-bucket keys may need equivalent msft values. Updating the browser code without the ad server can produce bids that never become eligible to serve.

4. Rebuild native and first-party-data logic

The Microsoft adapter does not support the legacy native ad-unit setup. Convert native requests to Prebid’s ORTB Native structure and include the required impression and viewability event trackers described in the documentation. Validate rendering, click-through behaviour, impression counting and viewability reporting.

The old appnexusAuctionKeywords option is also unsupported. Put site-level keywords in the appropriate standard first-party-data field, such as ortb2.site.keywords, or use the documented bidder-specific structure. Review purpose and consent before passing audience or identity data. Kayaar’s cross-platform data audit offers a useful governance framework.

5. Test consent and regional behaviour

Run the migration through each applicable privacy regime and consent state: accepted, rejected, unavailable and withdrawn. Confirm that TCF, GPP, US privacy and other supported signals pass as intended. Check network requests rather than relying only on the consent banner’s appearance.

Record which modules or vendors transform the consent string and who owns failures. Involve qualified privacy reviewers where needed. A technically successful bid request does not prove the data use is authorised.

6. Validate every media type

Test banner, video and native separately across representative placements. Check request payloads, bid responses, creative approval, VAST playback, native assets, clicks, viewability and ad-server delivery. Programmatic video needs particular attention because inventory and buyer requirements vary. Kayaar’s DV360 inventory readiness guide provides additional format and supply checks.

7. Roll out with controls and a rollback path

Start with a low-risk property or traffic share. Keep the legacy build available only as a temporary rollback while it remains supported, and define who can activate it. Compare the test cohort with the baseline and a stable control where possible.

Monitor demand, latency, consent errors and revenue closely after each release. Avoid unrelated floor, timeout or layout changes during the comparison. If the publisher also sells CTV inventory, the CTV campaign readiness guide highlights frequency, creative and measurement dependencies across the wider supply chain.

Final migration checklist

• Every AppNexus adapter instance and legacy endpoint is inventoried.
• The current supported Prebid.js version and Microsoft module are confirmed.
• Parameters, ad-server keys, native fields and first-party data are remapped.
• Consent signals pass correctly across required regions and states.
• Banner, video and native delivery are tested end to end.
• A phased launch, monitoring owner and rollback decision are documented.

The deadline is an infrastructure change, not a cosmetic rename. Treat it like a revenue-critical release with code review, privacy validation and measured deployment. For an independent implementation and analytics review, contact Kayaar.

FAQs