request: BizTalk map migration path information

[baidarka]

Thank you for this article! Could you please elaborate on re-use of BizTalk maps in Logic Apps in Azure? More specifically, we use BizTalk maps with functiods (and scripting functoids…) and those maps do not run on .Net Core (they require dot et framework). As LogicApps seem to support dotnet up to version 4.8, then our mappings will stop working when dotnet 4.8 support ends. Do you envision a migration path for this use case? Thanks in advance for any insights!

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 68834299-81ca-edf1-56ff-7c9527df6502
• Version Independent ID: 18e3448f-6c4f-eea1-a455-51bc0c1cfbdb
• Content: Migration approaches: BizTalk Server to Azure Integration Services - Azure Logic Apps
• Content Source: articles/logic-apps/biztalk-server-azure-integration-services-migration-approaches.md
• Service: logic-apps
• GitHub Login: @kewear
• Microsoft Alias: kewear

[Naveenommi-MSFT]

@baidarka Thanks for your feedback! We will investigate and update as appropriate.

[ecfan]

assign:kewear

[well0549]

Yes I am also curious about how to migrate now. Since we know the BizTalk Maps end of life is in sight, what other transformation tool could we use then. XSLT is so flexible, it allows for helper classes database lookups, and you can even do api calls in the helper classes. What other transformation tool should we invest in then ?

[kewear]

Here is some information on how you can use BizTalk Maps in Azure Logic Apps: https://techcommunity.microsoft.com/t5/azure-integration-services-blog/net-framework-assembly-support-added-to-azure-logic-apps/ba-p/3669120

Under the hood of a BizTalk map is XSLT. It is that artifact that you can bring to Azure Logic Apps. If you have functoids, including scripting functiod, you can bring those as well. However, the database functoids won't work in Logic Apps so that is a known limitation.

Using the approach above will allow you to 'lift and shift' your maps. You also have the opportunity to re-build maps using Data Mapper if you want as well. https://techcommunity.microsoft.com/t5/azure-integration-services-blog/announcement-azure-logic-apps-new-data-mapper-for-visual-studio/ba-p/3777138

It really becomes a priortization decision about whether you want to modernize your mappings now or incrementally once you are further along in your Logic Apps journey.

[well0549]

I know the xslt very well, but if some of the features (inline C# script) will no longer be available once 4.8 is eol. (They will never be available in .netCore.) So with years of investment in complex transformations (with a lot of helper classes and inline c# scripts) i am wondering if i lift & shift those maps to Azure..... We will then have the next task to get rid of all the inline scripts and move them to c# classes and call them there. Next I am not sure if the new data mapper will support custom helper classes as well. I had a look at the video and you only mentioned extensions very briefly.....

[kewear]

At this point, in the data mapper our custom extensibility is based upon XSLT 3.0. As of now, we don't have plans to support C# code. Here is a video the describes the custom extensibility in Data Mapper https://www.youtube.com/live/6bPc_K94B9s?si=WWbm45A_UJaKihnw&t=1201

[ecfan]

assign:ecfan

[ecfan]

@kewear, thanks for responding! Are there any doc action items to take here? If not, we can close the thread?

[kewear]

@ecfan We can close

[ecfan]

@kewear: Thank you!

please-close