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

UDE de Build Alma ve Deploy Sürecine Giriş

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

UDE’de Build Alma ve Deploy Sürecine Giriş

Lokal build, project/model/package yapısı, incremental deploy, database synchronization ve Power Platform Unified Package yaklaşımı

Serinin önceki bölümünde UDE tarafındaki custom metadata’yı Git repository içine nasıl yerleştirebileceğimizi, model ve proje dosyalarını nasıl versiyonlayacağımızı ve branch yapısını nasıl kurgulayabileceğimizi ele aldık.

Böylece kodumuz artık yalnızca geliştiricinin bilgisayarında duran dosyalardan çıkıp ekip tarafından izlenebilir bir kaynak haline geldi. Fakat repository’ye commit atmış olmamız geliştirmeyi tamamladığımız anlamına gelmiyor. Bir sonraki soru çok daha klasik: Yazdığımız kod gerçekten build oluyor mu ve bu kodu bağlı olduğumuz online UDE ortamında nasıl çalıştıracağız?

Klasik development VM yaklaşımında bu iki adım çoğu zaman aynı makinenin içinde gerçekleştiği için aradaki sınırı çok fazla düşünmüyorduk. Visual Studio, metadata, compiler, AOS ve çoğu zaman SQL Server aynı VM’in üzerindeydi. UDE’de ise geliştirme tarafı ile çalışma tarafı fiziksel olarak ayrılmış durumda.

Kod ve metadata lokal makinemizde; X++ kodunun çalışacağı runtime ise cloud tarafında. Dolayısıyla build ile deploy artık zihinsel olarak da iki ayrı adım.

Bu yazıda ağırlıklı olarak şu konulara bakacağız:

  • UDE’de lokal build’in ne anlama geldiği
  • Project, model ve package kavramlarının build açısından birbirinden farkı
  • Project Build, Rebuild ve Model Build seçenekleri
  • Lokal build sonrasında oluşan binary/package mantığı
  • Bağlı olduğumuz online UDE ortamına full ve incremental deploy seçenekleri
  • Database synchronization işleminin ne zaman gerekli olduğu
  • Deployable Package ile Power Platform Unified Package arasındaki fark
  • Günlük geliştirme için kullanabileceğimiz pratik build/deploy akışı

Yazının kapsamı: Bu bölümde Azure DevOps YAML build pipeline’ını baştan sona kurmayacağım. Önce geliştiricinin lokal makinesinde build ve online UDE’ye deploy mantığını netleştireceğiz. Otomatik build, NuGet paketleri, XppCreatePackage@3 ve pipeline artifact üretimini bir sonraki bölümde daha detaylı ele almak daha temiz olacak.

Read more

Introduction to Building and Deploying in UDE

Dynamics 365 F&O UDE Series | Part 8

Introduction to Building and Deploying in UDE

Local builds, the project/model/package structure, incremental deployment, database synchronization, and Power Platform unified packages

In the previous part of the series, we looked at how to place custom metadata in a Git repository, version model and project files, and design an appropriate branch structure for UDE.

Our code is therefore no longer a set of files that exists only on a developer’s computer; it is now a traceable source shared by the team. Committing the code to the repository, however, does not mean that development is complete. The next question is a familiar one: does the code actually build, and how do we run it in the connected online UDE environment?

With the classic development VM approach, both steps usually took place on the same machine, so we did not need to think much about the boundary between them. Visual Studio, metadata, the compiler, AOS, and often SQL Server were all hosted on the same VM. In UDE, the development tier and the execution tier are physically separated.

The code and metadata are on our local machine, while the runtime that executes the X++ code is in the cloud. Build and deployment must therefore be treated as two distinct steps.

In this article, we will focus on the following topics:

  • What a local build means in UDE
  • The differences between project, model, and package from a build perspective
  • Project Build, Rebuild, and Model Build options
  • The binary/package output produced by a local build
  • Full and incremental deployment options for the connected online UDE environment
  • When database synchronization is required
  • The difference between a deployable package and a Power Platform unified package
  • A practical daily build and deployment workflow

Scope of this article: This part does not build an Azure DevOps YAML pipeline from beginning to end. We will first clarify local builds and deployment to an online UDE environment. Automated builds, NuGet packages, XppCreatePackage@3, and pipeline artifacts will be covered in more detail in the next part.

Read more

Page 1 of 4612345102030...Last »