"},{"ID":26321,"user_firstname":"Sascha","user_lastname":"Brunner","nickname":"sbrunner","user_nicename":"sbrunner","display_name":"Sascha Brunner","user_email":"sbrunner@esri.com","user_url":"","user_registered":"2020-04-15 20:26:04","user_description":"","user_avatar":"
"}],"short_description":"Learn how to use AI to capture an existing application's requirements, recreate it using modern technologies, and validate the result.","flexible_content":[{"acf_fc_layout":"content","content":"Migrating applications can be time-consuming and repetitive, yet keeping them up to date is essential. Without regular modernization, years of investment can become increasingly difficult to maintain or may eventually be lost. This article shows how we used AI to capture an existing application’s requirements, recreate it using modern technologies, and validate the result.<\/span>\u00a0<\/span><\/p>\n With the transition from widgets to components in version 5.x of the ArcGIS Maps SDK for JavaScript, we took the opportunity to modernize our showcase applications and ensure they reflect current development patterns and technologies. We explored how AI could help automate large parts of the process, freeing up more time to focus on work that creates new value.<\/span>\u00a0<\/span><\/p>\n Not every migration requires the same approach. If your application only needs a small refactor, a version update, or limited widget changes, it is often perfectly reasonable to build on top of the existing codebase. Larger migrations are a different story. When you are not only upgrading the SDK, but also changing frameworks, adopting a new architecture, or jumping across multiple major releases, incremental upgrades can become increasingly time consuming. In these situations, it may be more efficient to focus on capturing the application’s requirements and recreating it from scratch using the desired technologies.<\/span>\u00a0<\/span><\/p>\n As with most migrations, there is no one-size-fits-all solution.<\/span> For complex projects, the decision is more nuanced and depends on both the scope of the migration and the complexity of the application itself. To compare different workflows, see the migration guides<\/span><\/span><\/a><\/span>\u00a0available in the SDK documentation.<\/span>\u00a0<\/span><\/p>\n To show how large migrations work in practice, w<\/span>e migrated the <\/span>Building Viewer<\/span><\/a> showcase by capturing its requirement and recreating the application from scratch. You can explore the new version here: <\/span>Building Viewer<\/span><\/a> and compare it with the original version here: <\/span>building-viewer\/version-4.<\/span><\/a>\u00a0<\/span><\/p>\n"},{"acf_fc_layout":"image","image":{"ID":2983146,"id":2983146,"title":"Building Viewer App","filename":"building-viewer-scaled.png","filesize":2240191,"url":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-scaled.png","link":"https:\/\/www.esri.com\/arcgis-blog\/products\/js-api-arcgis\/geoai\/rethinking-application-migrations\/building-viewer-2","alt":"Building Viewer App","author":"354432","description":"","caption":"Building Viewer Showcase","name":"building-viewer-2","status":"inherit","uploaded_to":2983144,"date":"2026-09-28 08:30:12","modified":"2026-09-28 10:54:12","menu_order":0,"mime_type":"image\/png","type":"image","subtype":"png","icon":"https:\/\/www.esri.com\/arcgis-blog\/wp-includes\/images\/media\/default.png","width":2560,"height":1387,"sizes":{"thumbnail":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-213x200.png","thumbnail-width":213,"thumbnail-height":200,"medium":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-scaled.png","medium-width":464,"medium-height":251,"medium_large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-scaled.png","medium_large-width":768,"medium_large-height":416,"large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-scaled.png","large-width":1920,"large-height":1040,"1536x1536":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-1536x832.png","1536x1536-width":1536,"1536x1536-height":832,"2048x2048":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-2048x1110.png","2048x2048-width":2048,"2048x2048-height":1110,"card_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-826x448.png","card_image-width":826,"card_image-height":448,"wide_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/building-viewer-1920x1040.png","wide_image-width":1920,"wide_image-height":1040}},"image_position":"center","orientation":"horizontal","hyperlink":""},{"acf_fc_layout":"content","content":" The goal was to upgrade ArcGIS Maps SDK, move from Dojo\/Grunt to Vite, TypeScript and ArcGIS Components. Because several major changes were happening at once, recreating the application proved more practical than attempting a series of incremental upgrades.<\/span>\u00a0<\/span><\/p>\n Throughout this process we used GitHub Copilot Chat in Visual Studio Code and a frontier model at the time (GPT-5.6), although the workflow itself is largely model and tool independent. What matters most is providing good context, clear instructions, and validating the results.<\/span>\u00a0<\/span><\/p>\n The general process looked like this:<\/span><\/p>\n"},{"acf_fc_layout":"image","image":{"ID":2983147,"id":2983147,"title":"General migration process","filename":"Drawing-2026-08-28-11.05.28.excalidraw.png","filesize":34889,"url":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","link":"https:\/\/www.esri.com\/arcgis-blog\/products\/js-api-arcgis\/geoai\/rethinking-application-migrations\/drawing-2026-08-28-11-05-28-excalidraw","alt":"General migration process diagram","author":"354432","description":"","caption":"","name":"drawing-2026-08-28-11-05-28-excalidraw","status":"inherit","uploaded_to":2983144,"date":"2026-09-28 10:56:55","modified":"2026-09-28 10:57:25","menu_order":0,"mime_type":"image\/png","type":"image","subtype":"png","icon":"https:\/\/www.esri.com\/arcgis-blog\/wp-includes\/images\/media\/default.png","width":848,"height":97,"sizes":{"thumbnail":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw-213x97.png","thumbnail-width":213,"thumbnail-height":97,"medium":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","medium-width":464,"medium-height":53,"medium_large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","medium_large-width":768,"medium_large-height":88,"large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","large-width":848,"large-height":97,"1536x1536":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","1536x1536-width":848,"1536x1536-height":97,"2048x2048":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","2048x2048-width":848,"2048x2048-height":97,"card_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw-826x94.png","card_image-width":826,"card_image-height":94,"wide_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2026\/09\/Drawing-2026-08-28-11.05.28.excalidraw.png","wide_image-width":848,"wide_image-height":97}},"image_position":"center","orientation":"horizontal","hyperlink":""},{"acf_fc_layout":"content","content":" The first step was creating a Product Requirements Document (PRD) describing the application’s functionality, interface, and behavior. Screenshots captured by the agent were particularly helpful because they provided visual context for UI states and interactions that would have been difficult to capture through text alone.<\/span>\u00a0<\/span><\/p>\n The goal was to document what the application does rather than how it was implemented. This helped avoid carrying over legacy implementation details and allowed us to focus on recreating the same experience using modern technologies.<\/span>\u00a0<\/span><\/p>\n We iterated on the PRD prompt several times to make it both useful for the AI and easy for humans to review. You can use the prompt below as a starting point for your own migration:<\/span>\u00a0<\/span><\/p>\n"},{"acf_fc_layout":"sidebar","content":" Create a PRD from this codebase only. I want to rebuild the exact same application from scratch using new technology. Document all current functionality, user flows, interactions, UI behavior, states (visible data, zoom levels, etc.), and requirements needed to recreate it. Focus only on extracting and documenting what exists today. Do not suggest implementation details, architecture, timelines, technology choices, improvements, or redesigns. Clearly distinguish between verified behavior, assumptions, and unknowns.\u00a0<\/em> You can check the PRD generated for our showcase here:<\/span> <\/span>PRD<\/span><\/span><\/a>.<\/span><\/span>\u00a0<\/span><\/p>\n"},{"acf_fc_layout":"content","content":" Using the PRD as a reference, we generated a completely new application based on the desired technology stack. Here is the prompt we used:<\/span><\/span>\u00a0<\/span><\/p>\n"},{"acf_fc_layout":"sidebar","content":" Build the new app from the PRD and screenshots. Use @arcgis\/create with Vite (references: https:\/\/developers.arcgis.com\/javascript\/latest\/get-started\/#use-arcgiscreate,\u00a0 https:\/\/www.npmjs.com\/package\/@arcgis\/create). Do not update any existing files, create a separate folder with the new app.\u00a0<\/em><\/p>\n","image_reference":false,"layout":"standard","image_reference_figure":"","snippet":"","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":"How we did it<\/h1>\n"},{"acf_fc_layout":"content","content":"
Capture the requirements<\/h2>\n"},{"acf_fc_layout":"content","content":"
\n\u00a0<\/em>
\nUse the integrated browser to run and test the application, not just inspect the source code. Include screenshots captured with Playwright throughout the document and place them in the relevant sections to illustrate views, workflows, dialogs, UI states, and important interactions.\u00a0<\/em>
\n\u00a0<\/em>
\nAt the beginning of the document, include a “Non-Conclusive Findings” section listing anything that could not be verified from code inspection or runtime testing and must be specified manually. Immediately below, include a “Data & Configuration Inventory” section containing:\u00a0<\/em>
\n– WebScene\/WebMap IDs and URLs\u00a0<\/em>
\n– Links\/URLs to referenced data sources and services\u00a0<\/em>
\n– Configuration values like descriptions, titles or file paths\u00a0<\/em>
\n– Any other discovered IDs, URLs, or externally referenced resources\u00a0<\/em>
\n\u00a0<\/em>
\nIf you find anything that you think is broken in the current version of the app, ask if it should be recorded as it is in the current state or improved.<\/em><\/p>\n","image_reference":false,"layout":"standard","image_reference_figure":"","snippet":"","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":"Recreate the application<\/span><\/span>\u00a0<\/span><\/h2>\n"},{"acf_fc_layout":"content","content":"