AI-Assisted Impact Analysis for Dynamics 365 FO Version Updates

Starting with our own code before a version update

Hello, in this article I will walk through an example of how we can use AI during Dynamics 365 version updates. When a new version arrives, are our customizations affected, where might issues arise, and which operations should we test? I wanted to look for answers to these questions in the code.

I have Microsoft packages for two different builds on my development machine. Each contains more than 170 packages and tens of thousands of objects. Rather than looking at all of them, I first identified where our own model connects to the standard code and compared the relevant objects.

I used Claude Code for this work. I asked it to prepare the comparison script, review the changed code together with our customization, and explain the impact. The check took a few minutes for this model.

Here, I am looking at customizations on the shared X++ and metadata infrastructure of Finance, Supply Chain Management, Commerce, and Human Resources. The results I am sharing come from code review. I have not yet compiled against the new version or run application tests.

The two builds I compared

The packages for the following two builds were already on the machine where I work with UDE. I used these folders for the comparison:

%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2527.116\PackagesLocalDirectory   (current)
%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2645.99\PackagesLocalDirectory    (new)

Read more

Dynamics 365 FO Versiyon geçişlerinde Yapay Zekâ ile Etki Analizi

Versiyon geçişine kendi kodumuzdan başlamak

Selamlar, bu yazıda Dynamics 365 sürüm geçişlerinde yapay zekâdan nasıl faydalanabileceğimizi bir örnek üzerinden anlatacağım. Yeni versiyon geldiğinde kendi geliştirmelerimiz etkileniyor mu, nerede sorun çıkabilir, hangi işlemleri test etmeliyiz? Bu sorulara kod üzerinden cevap aramak istedim.

Benim geliştirme makinemde iki farklı build’e ait Microsoft paketleri bulunuyor. Her birinde 170’ten fazla paket ve on binlerce nesne var. Hepsine bakmak yerine önce kendi modelimizin standart kodla bağlantılarını çıkarıp ilgili nesneleri karşılaştırdım.

Bu çalışma için Claude Code kullandım. Karşılaştırma betiğini hazırlamasını, değişen kodları bizim geliştirmemizle birlikte incelemesini ve etkisini açıklamasını istedim. Bu modelde kontrol birkaç dakika sürdü.

Burada Finance, Supply Chain Management, Commerce ve Human Resources’ın ortak X++ ve metadata altyapısındaki geliştirmeleri ele alıyorum. Paylaştığım sonuçlar kod incelemesine ait. Yeni sürüme karşı derleme ve uygulama testlerini henüz yapmadım.

Karşılaştırdığım iki build

UDE ile çalıştığım makinede aşağıdaki iki build’in paketleri zaten vardı. Karşılaştırmayı bu klasörler üzerinden yaptım:

%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2527.116\PackagesLocalDirectory   (mevcut)
%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2645.99\PackagesLocalDirectory    (yeni)

Read more

From XPO to XML: AI-Assisted X++ Code Upgrade from AX 2009 to Dynamics 365 ERP

When a move from AX 2009 to Dynamics 365 Finance & Operations comes up, one of the topics we focus on most is how to migrate the customizations developed over the years. In a system that has been in use for a long time, tables, classes, forms, and reports become part of the way the company operates. Identifying which customizations are still needed, understanding the existing business logic, and adapting it to the new version form an important part of the transition.

There are significant differences between the two versions from a development perspective. Finding the Dynamics 365 equivalent of an AX 2009 form, report, or modification to a standard object is not always straightforward. While we can migrate some structures in a similar way, others need to be reconsidered using the methods available on the new platform. Compiling the code alone is not enough, either. We need to check that forms, reports, and business rules work as expected.

So where can we use AI in this process? How can we establish a workflow for understanding X++ code, identifying dependencies between objects, and generating code suitable for the target version? This is one of the topics I have been working on recently. I believe we can use AI more systematically in the code upgrade process, particularly when we define transformation rules in advance and regularly validate the generated results.

In this article, we will use XPO files exported from AX 2009 as our starting point. We will examine the source objects with Claude Code, establish transformation rules, and migrate them to the metadata XML structure used by Dynamics 365. Throughout the process, we will discuss which changes are mandatory, where decisions are needed, and how we can check the generated objects. Using a car rental module, we will examine tables, forms, and the conversion of MorphX reports to SSRS step by step.

One point I particularly care about here is being able to trace the reasons behind the changes. We should be able to see how a field, method, or relationship is represented in the target version. When we find an error in the source code, we should also be able to distinguish it from the changes required for the version upgrade. The rule set and decision records we create will help us both control the transformation and reuse the knowledge in subsequent development work.

The scope of this article is the migration of application code and metadata structures. Migrating transaction data, balances, and historical transactions requires a separate effort. Here, we will focus on the process from code analysis through compilation in the target environment, using the forms, and generating report output.

Before we begin

Before moving on to code migration, we need to prepare the source files and the target development environment. It is just as important for AI to know which structure to use when creating objects and how to validate them as it is for it to read the source code. We will therefore begin by bringing together XPO files, labels, working examples from the target environment, and compilation tools.
Read more

XPO’dan XML’e: Yapay Zekâ Desteğiyle AX 2009’dan Dynamics 365’e X++ Kod Yükseltme

AX 2009’dan Dynamics 365 Finance & Operations’a geçiş gündeme geldiğinde, üzerinde en çok durduğumuz konulardan biri yıllar içinde yapılan geliştirmelerin nasıl taşınacağı oluyor. Uzun süredir kullanılan bir sistemde tablolar, sınıflar, formlar ve raporlar şirketin iş yapış biçiminin bir parçası haline geliyor. Bu geliştirmelerin hangilerine hâlâ ihtiyaç olduğunu belirlemek, mevcut iş mantığını anlamak ve yeni sürüme uyarlamak geçişin önemli bir bölümünü oluşturuyor.

İki sürüm arasında geliştirme açısından ciddi farklar var. AX 2009’daki bir formun, raporun veya standart nesne üzerinde yapılan değişikliğin Dynamics 365’teki karşılığını bulmak her zaman kolay olmuyor. Bazı yapıları benzer şekilde taşıyabilirken bazılarını yeni platformun sunduğu yöntemlerle yeniden ele almamız gerekiyor. Üstelik kodun derlenmesi de tek başına yeterli değil. Formların, raporların ve iş kurallarının beklediğimiz şekilde çalıştığını kontrol etmemiz gerekiyor.

Peki, yapay zekâyı bu sürecin neresinde kullanabiliriz? X++ kodunu anlamak, nesneler arasındaki bağımlılıkları çıkarmak ve hedef sürüme uygun kod üretmek için nasıl bir çalışma düzeni kurabiliriz? Son dönemde üzerinde çalıştığım konulardan biri bu. Özellikle dönüşüm kurallarını önceden tanımladığımızda ve üretilen sonucu düzenli olarak doğruladığımızda, kod yükseltme sürecinde yapay zekâdan daha sistemli şekilde yararlanabileceğimizi düşünüyorum.

Bu yazıda AX 2009’dan aldığımız XPO dosyalarını başlangıç noktası olarak kullanacağız. Claude Code ile kaynak nesneleri inceleyecek, dönüşüm kurallarını oluşturacak ve Dynamics 365’in kullandığı metadata XML yapısına taşıyacağız. Süreç boyunca hangi değişikliklerin zorunlu olduğunu, hangi noktalarda karar vermemiz gerektiğini ve üretilen nesneleri nasıl kontrol edebileceğimizi ele alacağız. Araç kiralama modülü üzerinden tabloları, formları ve MorphX raporlarının SSRS’e dönüşümünü adım adım inceleyeceğiz.

Burada özellikle önemsediğim konu, yapılan değişikliklerin nedenini takip edebilmek. Bir alanın, metodun veya ilişkinin hedef sürümde nasıl karşılandığını görebilmeliyiz. Kaynak kodda bir hata bulduğumuzda da bunu sürüm geçişi için gereken değişikliklerden ayırabilmeliyiz. Oluşturacağımız kural seti ve karar kayıtları, hem dönüşümü kontrol etmemizi hem de sonraki geliştirmelerde aynı birikimden yararlanmamızı sağlayacak.

Yazının kapsamı uygulama kodunun ve metadata yapısının taşınması olacak. İşlem verilerinin, bakiyelerin ve geçmiş hareketlerin aktarılması ayrı bir çalışma gerektiriyor. Burada kodun analizinden başlayıp hedef ortamda derlenmesine, formların kullanılmasına ve rapor çıktılarının alınmasına kadar uzanan sürece odaklanacağız.

Başlamadan önce

Kod taşıma sürecine geçmeden önce kaynak dosyaları ve hedef geliştirme ortamını hazırlamamız gerekiyor. Yapay zekânın kaynak kodu okuyabilmesi kadar, ürettiği nesneleri hangi yapıya göre oluşturacağını ve nasıl doğrulayacağını bilmesi de önemli. Bu nedenle çalışmaya XPO dosyaları, etiketler, hedef ortamda çalışan örnekler ve derleme araçlarını bir araya getirerek başlayacağız.
Read more

Nashville’de On Gün: Community Summit, X++, Yapay Zekâ ve Biraz Amerika

Bazı seyahatlerden dönerken aklınızda gezdiğiniz yerler, bazılarında tanıştığınız insanlar, bazılarında ise öğrendikleriniz kalıyor. Bu Amerika yolculuğunda bunların hepsi bir araya geldi.

Community Summit North America 2026’ya katılmak ve bir buçuk saatlik bir sunum yapmak için gittiğim Nashville’de oldukça dolu günler geçirdim. Oturumlara katıldım, birçok firma ve sektör profesyoneliyle tanıştım, Microsoft iş uygulamaları ekosisteminin Amerika’daki büyüklüğünü yakından gördüm. Etkinlik sonrasında da Nashville ve çevresini gezme, biraz şehir hayatını, biraz da Amerika’nın büyük şehirlerin dışında kalan yüzünü tanıma fırsatım oldu.

Bu yazıda teknik detaylardan biraz uzaklaşıp yolculuktan aklımda kalanları paylaşmak istiyorum. Tabii araya X++, yapay zekâ ve birkaç sektör gözlemi de girecek. Meslek hastalığı diyelim.

Community Summit’te bir araya geldiğimiz arkadaşlarla.

Elif Item Hanım’a organizasyon ve fotoğraf için ayrıca teşekkürler. Kendisiyle karşılaşmak ve sohbet etmek çok güzeldi.

İstanbul’dan Chicago’ya, oradan Nashville’e

Yolculuğum İstanbul’dan Chicago’ya uçuşla başladı. Uzun bir uçuşun ardından Amerika’ya giriş ve sonrasında Nashville’e geçiş… Böyle yolculuklarda saat farkı, havaalanları ve aktarmalar derken günün hangi saatinde olduğunuzu bir noktadan sonra biraz kaybediyorsunuz.

Chicago bu seyahatte benim için ağırlıklı olarak bir aktarma noktasıydı. Asıl hedef, Tennessee eyaletindeki Nashville’di.

Bir etkinliğe giderken her zaman benzer bir heyecan oluyor: Kimlerle karşılaşacağız, hangi konular konuşulacak, sunum nasıl geçecek? Bu defa bunlara Amerika’daki topluluğu daha yakından tanıma merakı da eklenmişti.

İstanbul’dan Nashville’e uzanan yolculuktan.

Nashville: Müziğin şehrin içine karıştığı yer

Nashville denince country müzikten bahsetmeden geçmek mümkün değil. Şehirde müzik, akşam gidilen bir etkinliğin ötesinde, günlük hayatın bir parçası gibi.

Bunu en çok Broadway’de hissediyorsunuz. Yan yana sıralanmış canlı müzik mekânları, farklı kapılardan sokağa yayılan sesler, neon tabelalar ve kalabalık… Birkaç adım yürüdüğünüzde duyduğunuz müzik değişiyor. Özellikle Lower Broadway bölgesi, şehrin bu canlı müzik kültürünün merkezlerinden biri.

Country müzikle çok yakından ilgilenmeseniz bile ortamın içine girmek kolay. Müzisyenlerin performansı, insanların müzikle kurduğu ilişki ve sokaktaki hareketlilik şehre kendine özgü bir karakter veriyor.

Read more

Ten Days in Nashville: Community Summit, X++, AI, and a Little of America

I spent several busy days in Nashville, attending Community Summit North America 2026 and delivering a 90-minute session. I joined sessions, met people from many companies across the industry, and saw the scale of the Microsoft business applications ecosystem in the US firsthand. After the event, I also had the chance to explore Nashville and the surrounding region, experiencing both city life and a side of America beyond its major cities.

In this post, I want to step away from the technical details for a while and share what stayed with me from the trip. Of course, a little X++, AI, and a few industry observations will still find their way in. An occupational hazard, I suppose.

With friends at Community Summit.

A special thank you to Elif Item for organizing the gathering and for the photo. It was lovely to see her and catch up.

From Istanbul to Chicago, then on to Nashville

My journey began with a flight from Istanbul to Chicago. After a long flight came entry into the US, followed by the connection to Nashville. Between the time difference, airports, and connecting flights, you eventually start to lose track of what time of day it is.

On this trip, Chicago was mainly a connection point for me. The real destination was Nashville, Tennessee.

There is always a familiar sense of anticipation when heading to an event: Who will we meet? What will people be talking about? How will the session go? This time, I was also looking forward to getting to know the US community better.

On the journey from Istanbul to Nashville.

Read more

UDE, Pipelines, and Modern ALM: Moving Development to Test and Production

Dynamics 365 F&O UDE Series | Part 10

UDE, Pipelines, and Modern ALM: Moving Development to Test and Production

The Dev-Test-UAT-Prod promotion model, release branches, immutable artifacts, approvals/checks, and a controlled deployment strategy
August 2026 | Fatih Demirci | fatihdemirci.net

Introduction

In the previous part, we built a pipeline that compiles the X++ metadata in our Git repository on a Microsoft-hosted agent and produces a Power Platform unified package. We now have a UnifiedPackage built from a specific Git commit with specific NuGet references and stored as an Azure DevOps artifact.

However, producing the package does not mean that we have moved the development to UAT or Production. If we do not draw a clear boundary between build and deployment, we end up rebuilding for every environment, losing visibility of who approved what, and being unable to trace the code in Production back to a specific commit.

In this part, we will examine the release/deployment pipeline that promotes the build output through Test, UAT, and Production in a controlled manner. We will clarify the branch strategy, approvals and checks in Azure DevOps Environments, the service connection structure, and deployment rules. At the end, we will monitor the package sent from DevOps in a real Test/UAT environment and verify that our development has reached the F&O user interface.

Where this part fits in the series: We are completing the development, Git, branch, build, and package structure established in the earlier parts with a real Test/UAT deployment. The same artifact, approval, and traceability principles will also apply when moving to Production.

What We Carry Forward from the Previous Part

At the end of Part 9, the build pipeline produced the following information together:

  • Git commit SHA and branch information

  • Platform and application NuGet versions

  • Build.BuildNumber and the pipeline run link

  • Power Platform UnifiedPackage.zip artifact

  • The classic AXDeployableRuntime.zip output, when required

The release pipeline is not responsible for compiling the source code again. Its job is to move this controlled output to the correct environment under the correct identity.

Core principle: Build once and promote the same artifact. The package validated in Test and the package deployed to Production must be byte-for-byte identical.

Read more

UDE, Pipeline ve Modern ALM: Geliştirmeyi Test ve Canlı Ortama Taşımak

Dynamics 365 F&O UDE Serisi | Bölüm 10

UDE, Pipeline ve Modern ALM: Geliştirmeyi Test ve Canlı Ortama Taşımak

Dev-Test-UAT-Prod geçiş mantığı, release branch, immutable artifact, approval/check yapısı ve kontrollü deployment stratejisi
Ağustos 2026 | Fatih Demirci | fatihdemirci.net

Giriş

Serinin önceki bölümünde Git repository içindeki X++ metadata’yı Microsoft-hosted bir agent üzerinde derleyen ve Power Platform unified package üreten build pipeline’ı kurduk. Artık elimizde belirli bir Git commit’inden, belirli NuGet referanslarıyla üretilmiş ve Azure DevOps artifact’i olarak saklanan bir UnifiedPackage var.

Fakat package’ın üretilmiş olması geliştirmeyi UAT veya production ortamına taşıdığımız anlamına gelmiyor. Build ile deploy arasındaki sınırı doğru çizmezsek her ortam için yeniden build alınan, kimin neyi onayladığının belli olmadığı ve canlıdaki kodun hangi commit’e karşılık geldiğinin izlenemediği bir yapı oluşur.

Bu bölümde build çıktısını Test, UAT ve Production ortamlarına kontrollü şekilde ilerleten release/deploy pipeline’ı ele alacağız. Branch stratejisini, Azure DevOps Environments üzerindeki approval ve check mekanizmalarını, service connection yapısını ve deployment kurallarını netleştireceğiz. Yazının sonunda ise DevOps’tan gönderdiğimiz paketi gerçek bir Test/UAT ortamında izleyip geliştirmemizin F&O arayüzüne ulaştığını göreceğiz.

Bu bölümün serideki yeri: İlk bölümlerde kurduğumuz development, Git, branch, build ve package yapısını gerçek bir Test/UAT deployment’ıyla tamamlıyoruz. Production’a geçişte de aynı artifact, onay ve izlenebilirlik prensipleri kullanılacak.

Önceki Bölümden Devraldığımız Çıktı

Bölüm 9′un sonunda build pipeline aşağıdaki bilgileri birlikte üretiyordu:

  • Git commit SHA ve branch bilgisi

  • Platform ve application NuGet sürümleri

  • Build.BuildNumber ve pipeline run bağlantısı

  • Power Platform UnifiedPackage.zip artifact’i

  • İhtiyaç varsa klasik AXDeployableRuntime.zip çıktısı

Release pipeline’ın görevi source code’u yeniden derlemek değil, bu kontrollü çıktıyı doğru kimlikle doğru ortama taşımaktır.

Temel ilke: Bir kez build et, aynı artifact’i ilerlet. Test’te doğrulanan package ile Production’a çıkan package byte olarak aynı olmalıdır.

Dev, Test, UAT ve Production Aynı Şeyi İfade Etmez

UDE tarafında Development ortamı ile kontrollü deployment ortamlarını birbirinden ayırmak gerekiyor. Development günlük geliştirme döngüsünün parçasıdır; Test, UAT ve Production ise release yönetiminin parçasıdır.

Read more

Ortam Temel amaç Deployment yaklaşımı Onay

UDE Build and Package Creation with an Azure DevOps Pipeline

Dynamics 365 F&O UDE Series | Part 9

UDE Build and Package Creation with an Azure DevOps Pipeline

NuGet packages, Azure Artifacts, YAML pipelines, X++ builds, and Power Platform unified package creation
August 2026 | fatihdemirci.net

Introduction

In the previous part of the series, we discussed how a local build and deployment to an online UDE environment are separate steps. During day-to-day development, we can run a quick project build in Visual Studio and deploy our changes to the connected environment.

When we move to controlled environments such as UAT or production, however, a build created on a developer’s computer is not enough. The same Git commit must be compiled against the same references, and the resulting package must be stored as a pipeline artifact.

In this part, we will create an Azure DevOps YAML pipeline that runs on a Microsoft-hosted Windows agent. The pipeline will compile the X++ metadata in the repository, create a unified package and, when required, a traditional deployable package, and then publish the outputs as artifacts.

Scope of this article: This part focuses on build and package creation. Deploying the resulting unified package to Test, UAT, and Production environments with approval mechanisms will be the subject of the next part.

Overall Flow

At its simplest, we can think of the build pipeline as the following flow:

Input Process Output
Git repository NuGet restore Compiler and reference packages
Metadata + .sln/.rnrproj Compile X++ with VSBuild / MSBuild X++ binary outputs
X++ binary outputs XppCreatePackage@3 Unified package and/or deployable package
Package outputs PublishBuildArtifacts Artifact consumed by the release pipeline

Read more

Azure DevOps Pipeline ile UDE Build ve Package Üretimi

Dynamics 365 F&O UDE Serisi | Bölüm 9

Azure DevOps Pipeline ile UDE Build ve Package Üretimi

NuGet paketleri, Azure Artifacts, YAML pipeline, X++ build ve Power Platform unified package üretimi
Ağustos 2026 | fatihdemirci.net

Giriş

Serinin önceki bölümünde lokal build ile online UDE ortamına deploy işleminin farklı adımlar olduğunu ele aldık. Günlük geliştirmede Visual Studio ile hızlı bir project build alıp değişiklikleri bağlı olduğumuz ortama gönderebiliyoruz.

UAT veya production gibi kontrollü ortamlara çıktığımızda ise geliştiricinin bilgisayarında alınan build yeterli değil. Aynı Git commit’inin aynı referanslarla derlenmesi ve ortaya çıkan package’ın pipeline artifact’i olarak saklanması gerekiyor.

Bu bölümde Microsoft-hosted Windows agent üzerinde çalışan bir Azure DevOps YAML pipeline kuracağız. Pipeline repository’deki X++ metadata’yı derleyecek, unified package ve ihtiyaç varsa klasik deployable package üretecek, ardından çıktıları artifact olarak yayınlayacak.

Yazının kapsamı: Bu bölüm build ve package üretimine odaklanıyor. Üretilen unified package’ın Test, UAT ve Production ortamlarına approval mekanizmalarıyla dağıtılması bir sonraki bölümün konusu olacak.

Genel Akış

Build pipeline’ın yaptığı işi en basit haliyle aşağıdaki akışta düşünebiliriz:

Girdi İşlem Çıktı
Git repository NuGet restore Compiler ve reference paketleri
Metadata + .sln/.rnrproj VSBuild / MSBuild ile X++ compile X++ binary çıktıları
X++ binary çıktıları XppCreatePackage@3 Unified package ve/veya deployable package
Package çıktıları PublishBuildArtifacts Release pipeline’ın kullanacağı artifact

Read more

Page 1 of 4712345102030...Last »