The document provides a detailed architectural assessment for migrating a six‑year‑old Xamarin mobile app that implements agricultural yield calculations (BLUP, Site Variety Value, Cluster Variety Value, PEV error bars) to a modern stack consisting of a React frontend and Azure Functions backend. It first categorises the existing codebase into portable pure‑logic classes, mixed Xamarin‑specific code, and platform‑only components, explaining which parts can be moved unchanged and which must be rebuilt. Two migration paths are evaluated: (A) extracting the pure C# calculation logic into Azure Functions (C#) and wrapping it with HTTP triggers, and (B) translating the logic to TypeScript for client‑side or Node.js execution. The pros and cons of each path are discussed, with a focus on numerical fidelity, performance, and developer effort. The assessment then analyses how AI tools (LLMs, code‑generation assistants) can accelerate boilerplate creation, documentation, and syntax translation, while highlighting high‑risk failure modes such as silent numerical drift, incorrect API mapping, and loss of precision when moving from C# double/decimal to JavaScript number. A scale‑based break‑even analysis shows when a clean‑room rebuild becomes more efficient than extraction ( >15 tightly‑coupled modules, no tests). A practical migration plan is proposed: a half‑day triage with the original developer to label classes, direct extraction of pure‑logic classes into an Azure Functions project, rebuilding data‑loading, storage, and UI layers in React, and constructing a validation harness that compares outputs of the legacy Xamarin app with the new service on a set of known inputs. The document then deep‑dives into the NVT Long‑Term Yield (LTY) reporter – the live system the migration targets. It describes the core matrix table UI (variety × site/year grid with colour‑coded BLUP predictions, filters, cluster building, and PEV error bars), and identifies the UI as a complex, spreadsheet‑like component best implemented with a data‑grid library such as AG Grid or TanStack Table. It discovers that the existing production backend is a Vue.js SPA calling a custom REST API (https://app.nvt.grdc.com.au/backend/), which already performs batch BLUP calculations and returns pre‑aggregated data. This implies that the Xamarin app may have been a consumer rather than the host of the heavy calculations, shifting the migration focus toward re‑using the existing API where possible and only extracting calculation kernels for on‑demand cluster or site calculations. Finally, a revised migration decision tree maps each component (BLUP batch, SVV/CVV endpoints, filter logic, UI grid, colour‑coding, "present‑in‑trial" flag) to the recommended approach (extract to Azure Functions, rebuild in React, or keep existing API). The overall recommendation is to extract the pure C# math kernels into Azure Functions, rebuild the React UI with a robust grid component, and rely on the existing backend for data serving, while using AI for low‑risk scaffolding and maintaining a strict validation regime.
Topics
Pure‑Logic Extraction: Identifying High‑Value, Low‑Risk C# Classes
Classification of Xamarin code into pure algorithmic modules (BLUP, SVV, CVV, PEV) that have no Xamarin dependencies and can be moved unchanged.
Scale‑Based Break‑Even Analysis
Guidelines for when a clean‑room React rebuild outweighs extraction based on module count, test coverage, and coupling.
Existing Vue.js Backend API Discovery
Findings about the production REST API, batch BLUP computation, data aggregation, authentication, and implications for migration.