Converting Power BI Maps and Filled Maps to Azure Maps Visuals - When to Bother and When to Leave It

If you have a Power BI report with a map on it, there is a decent chance that map is built on a visual Microsoft would quietly like you to stop using. The old Map and Filled map (choropleth) visuals have been around since the early days, they rely on Bing under the hood, and Microsoft has been steering everyone toward Azure Maps for a while now. The conversion feature that lets you flip an existing map to an Azure Maps visual is the polite nudge that says "you should probably move".

I want to talk through what that conversion actually does, because on the surface it sounds like a one-click job and in practice it is a decision worth thinking about. We do a fair amount of this on client reports, some of it planned and some of it because a map suddenly stopped rendering the way it used to, and there are a few things worth knowing before you start clicking convert on everything.

Microsoft's documentation on converting to Azure Maps visuals covers the mechanics. What I want to add is the judgement part: whether you should, when you should, and what tends to go sideways.

Why this is even happening

Australian businesses lean on maps more than you might think. A logistics company wants delivery density by postcode. A retailer wants store performance shaded across a state. A mining services firm wants sites plotted against a region. Property, agriculture, government, insurance, all of them end up with a map somewhere in the reporting because geography is genuinely part of the story.

The old map visuals did the job for years, but they are showing their age. Azure Maps is the newer engine, it has better rendering, more layer types, proper support for things like heat maps and 3D column layers, and it is where Microsoft is putting its effort. The Bing-based visuals are not getting new features. So the conversion is not really about a nicer map today, it is about not being stranded on a visual that stops getting attention. That is the honest reason to care.

If you are running geospatial reporting as a serious part of your analytics, this is the kind of platform decision worth getting right early, and it is squarely the sort of thing our Power BI consultants end up advising on.

What the conversion actually does

Here is the useful bit. When you select an old Map or Filled map visual on the canvas, Power BI gives you the option to convert it to an Azure Maps visual, and it carries your field wells across. Your Location, Latitude, Longitude and Legend fields come over, so you are not rebuilding the data bindings from scratch. That is the good news and it is genuinely handy, because rewiring fields by hand across a report full of maps is tedious and error-prone.

What does not come across cleanly is formatting. The two visuals have different formatting models. Azure Maps has its own set of layers, its own styling options, its own idea of what a bubble or a filled region should look like. So the conversion gets your data onto the new visual, but the look of it is going to need a pass. Colours, bubble sizing, the reference layer for filled regions, zoom behaviour, all of that is worth checking rather than assuming it survived.

My blunt take: treat the conversion as "it moves the data, you redo the polish". If you go in expecting a pixel-perfect swap you will be annoyed. If you go in expecting to get the data wired up for free and then spend ten minutes restyling, you will be happy. Set the expectation correctly and it is a good feature.

The filled map catch worth knowing about

Filled maps are where people trip. The old Filled map visual shades regions, states, postcodes, countries, based on a location field, and it leans on Bing to work out the shape of each region. Azure Maps handles filled regions differently. For proper region shading you often want to be working with the reference layer or supplying your own boundaries, and if your old report was relying on Bing quietly guessing postcode boundaries, the behaviour can shift.

For Australian data this matters more than it does in the US, because our postcode and suburb boundaries are not always as neatly supported out of the box. I have seen a filled map of Australian postcodes that looked fine on the old visual come across to Azure Maps and need real work to shade correctly. It is not that Azure Maps is worse, it is that it is more explicit about where the boundaries come from, and that explicitness surfaces assumptions the old visual was hiding.

So if your maps are bubble maps, plotting points by lat/long or by city, the conversion tends to be smooth. If your maps are filled region maps shading Australian geography, budget more time and test them against known data before you trust them in front of anyone.

When I would convert now, and when I would wait

Not every map needs to move today. Here is roughly how I think about it.

Convert now if the map is important, visible, and you are actively working on that report anyway. If someone senior looks at it regularly, you want it on the engine that is getting investment, and doing it while you already have the report open is the cheapest time to do it. Also convert now if you want the newer capabilities, heat maps, 3D columns, multiple layers, because the old visual simply cannot do those and no amount of waiting changes that.

Wait if the map is buried in a report nobody touches, works fine, and you have no appetite for restyling right now. There is no emergency. The old visuals still render. Forcing a migration across fifty dusty reports in one hit, purely for tidiness, is the kind of project that eats a week and delivers nothing a user will notice. Do it opportunistically as you touch each report instead.

The one thing I would not do is build anything new on the old map visuals. If you are creating a fresh report today, start on Azure Maps. There is no good reason to add to the pile of things you will eventually have to convert.

The stuff that catches teams out

A few practical notes from doing this on real reports.

Azure Maps has to be enabled for your organisation. It is governed by a tenant setting, and in a lot of Australian enterprises the person building the report is not the person who controls tenant settings. So you go to convert a map, the Azure Maps visual is not available, and you burn twenty minutes before realising it is an admin switch, not a bug. Check that the tenant setting is on before you plan a migration, because it can involve a conversation with whoever owns your Power BI governance.

Region and privacy questions come up too. Azure Maps is an Azure service, and for organisations that care deeply about data residency, and plenty of Australian government and financial services clients do, it is worth understanding what location data is being sent where. It is usually fine, but "usually fine" is not the answer a risk team wants, so get the specifics if you operate under strict data handling rules. This kind of platform governance question is exactly what we work through on Microsoft and Azure AI engagements, because the same residency concerns show up across the whole stack.

And test the converted visual against numbers you already trust. The quickest way to lose faith in a new map is to convert it, glance at it, and later discover a region was shading off the wrong boundary the whole time. Pick a few data points you know cold and confirm the new map agrees with them before you move on.

What good looks like

When we handle this properly for a client, it is not a big-bang migration. It is a policy: new maps go on Azure Maps, existing maps get converted as we touch each report, and the important high-visibility maps get moved deliberately with a proper restyle rather than a rushed one. The tenant setting gets sorted once, up front, so nobody hits the wall mid-build. Filled maps of Australian geography get extra testing because that is where the surprises live.

Done that way, the whole thing is quiet. Reports keep working, the maps slowly modernise, and you are never stranded on a visual that stopped getting attention. The mistake is treating it as either an emergency or a non-event. It is neither. It is a sensible migration that rewards being done on purpose rather than in a panic or not at all.

If you have got a pile of Power BI reports leaning on the old map visuals and you are not sure which to move or how much work it is, that is a very answerable question. Have a look at our data and analytics services or just get in touch and we will take a look at what you have got and what is actually worth converting.