# Migrate a deprecated API across every callsite in F# with Atlas in 2026 > Atlas ensures a complete migration of deprecated F# APIs by enumerating all callsites, tracking progress, and verifying changes with dotnet test (Expecto) and fantomas. Migrating a deprecated F# API across an entire codebase without missing a callsite is a precise job that Atlas handles by front-loading enumeration and integrating directly with your F# toolchain. Atlas uses the lsp tool to find all references, tracks each migration with todowrite, and verifies changes with dotnet test (Expecto) and fantomas before committing. ## Key takeaways - Atlas combines `lsp` and `grep` for comprehensive enumeration of F# API calls. - Todowrite provides granular, visible tracking for every F# migration step. - Apply_patch ensures safe, context-anchored modifications to F# source files. - Atlas integrates `dotnet test (Expecto)` and `fantomas` for immediate F# code verification. - Unified diffs and permission prompts offer full control over F# code changes. - Final `grep` confirms complete removal of deprecated F# symbols. ## How does Atlas find all deprecated F# API calls? To find every deprecated F# API call, Atlas employs a hybrid approach, combining the lsp tool's findReferences with grep. This ensures that by 2026, no callsite, whether AST-linked or dynamically referenced, is missed, providing a complete enumeration for your F# migration. Atlas begins the migration process by comprehensively enumerating all callsites of the deprecated F# symbol. It leverages the lsp tool's findReferences operation, which queries the language server to yield a complete set of callers based on the Abstract Syntax Tree (AST). This method is highly effective for statically linked references within your F# codebase, respecting F# specific constructs like discriminated unions, modules, and computation expressions. To catch any dynamic or string-based usages that the language server might miss, Atlas cross-checks with the grep tool. For instance, if your F# code uses `nameof` or constructs a function name dynamically, `atlas grep "MyDeprecatedModule.MyDeprecatedFunction" src/**/*.fs` will identify these instances. Atlas builds its code index with local Ollama embeddings, ensuring your F# code remains off third-party servers while providing robust semantic search capabilities. This dual approach guarantees that every single callsite in your F# project, from a simple function call in `Domain.fs` to a module reference in `Web.fs`, is identified before any migration work begins. ## How does Atlas track progress for F# API migrations? Tracking the progress of a large F# API migration is crucial to avoid missed callsites. Atlas addresses this by creating one todowrite entry for each identified callsite, ensuring that partial progress is always visible and no single migration step is silently skipped across your 100s of F# files. Once all deprecated F# API calls have been enumerated, Atlas transforms this list into a set of actionable tasks using the todowrite tool. For every identified callsite, Atlas creates a distinct todowrite entry. This granular approach ensures that partial progress is always visible, preventing any callsite from being silently skipped or forgotten during a complex migration involving many F# files. Each entry typically includes the file path and line number, such as `src/MyProject/Domain.fs:123`, making it easy to pinpoint the exact location in your F# codebase that requires modification. As each callsite is successfully migrated and verified, its corresponding todowrite entry is marked as completed. This systematic tracking provides a clear, real-time overview of the migration status, allowing F# developers to monitor progress and ensure that the entire codebase is moved off the deprecated API without missing a single caller. ## How does Atlas safely apply changes to F# code? Safely applying changes to F# code during a migration is paramount to prevent errors. Atlas uses the apply_patch tool, which performs context-anchored modifications. This means it will fail rather than misapply a patch to a drifted file, providing a 100% reliable update mechanism for your .fs files. for modifying your F# source files, Atlas employs the apply_patch tool, designed for maximum safety and reliability. Instead of blindly applying changes based on line numbers, apply_patch seeks the hunk's context and old_lines within the target file. This context-anchored patching mechanism is critical for F# code, where precise indentation and syntax are vital. If the target F# file has drifted since the patch was generated (e.g., due to concurrent edits), apply_patch will detect this discrepancy and throw a "Failed to find expected lines" error rather than attempting to guess or misapply the patch. This robust failure mode prevents unintended or incorrect modifications to your `.fs` or `.fsi` files, safeguarding the integrity of your F# codebase. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, giving you complete control and visibility over every change made to your F# project. ## How does Atlas verify F# API migrations with tests and formatting? Verifying F# API migrations immediately after each change is essential for maintaining code quality. Atlas integrates directly with your F# toolchain, running dotnet test (Expecto) via bash after each file modification. It also ensures consistent formatting by running fantomas over the changed .fs files, typically within 1-2 seconds. Atlas ensures the correctness and consistency of your F# codebase throughout the migration by integrating with your existing F# toolchain. After each file modification, Atlas uses the bash tool to run the affected tests. For F# projects, this means executing `dotnet test --project MyTests.fsproj`, which will run your `Expecto` tests. Atlas prompts for permission before running `dotnet test`, allowing you to review and approve the action. Only once these tests pass is the corresponding todowrite entry marked as completed, ensuring that each migration step is fully validated. Furthermore, to maintain code consistency and adhere to your project's style guidelines, Atlas can run `fantomas` over the changed `.fs` files. This is achieved by executing `atlas bash "dotnet fantomas src/MyProject/MyFile.fs"`, ensuring that all migrated F# code is correctly formatted. This immediate feedback loop, combining testing and formatting, significantly reduces the risk of introducing regressions or style inconsistencies during the migration. ## What are Atlas's safety and review mechanisms for F# code changes? Atlas provides robust safety and review mechanisms for F# code changes, ensuring you maintain full control. Before any modification, Atlas drafts a plan in a read-only agent and presents a unified diff for every file edit. All tool calls are permission-gated, giving you 100% oversight of the migration process. Atlas is built with a strong emphasis on user control and safety, especially when making significant changes to your F# codebase. The workflow begins with Atlas drafting a plan in a read-only plan agent. This allows you to review the proposed F# migration strategy before any code is touched. Once approved, Atlas switches to a build agent for execution. Every Atlas tool call, including running `dotnet test (Expecto)` or `fantomas`, is permission-gated against allow, ask, and deny rules, ensuring that no action is taken without your explicit consent. For every file edit, Atlas computes a unified diff and surfaces it for your approval before writing to disk. This granular review process means you can inspect every change to your `.fs` files. Atlas also reads git branches, status, and diffs, and can stage and create commits on your behalf, providing direct integration with your version control. Furthermore, Atlas snapshots file changes as git patches, so edits can be diffed and rolled back easily, offering a robust safety net for your F# project. ## How does Atlas ensure zero remaining deprecated F# API calls? Ensuring zero remaining deprecated F# API calls is the final, critical step in any migration. Atlas concludes the workflow by performing a final grep for the deprecated symbol across your entire F# codebase. This confirms that all 0 instances have been successfully replaced, allowing safe deletion of the old implementation. The ultimate goal of migrating a deprecated F# API is to completely remove all its usages. Atlas ensures this by performing a final verification step. After all todowrite entries are marked complete and all individual migrations are done, Atlas runs a comprehensive `grep` for the deprecated symbol across the entire F# codebase. This command, such as `atlas grep "MyDeprecatedModule.MyDeprecatedFunction" src/**/*.fs`, serves as a final audit to confirm that there are absolutely zero remaining hits of the old API. This rigorous check prevents any overlooked instances from lingering in your F# project. Once this final `grep` confirms a clean slate, you can confidently proceed to delete the old F# implementation, such as removing `src/MyProject/DeprecatedModule.fs` or the specific function definition. This systematic approach guarantees a thorough and complete migration, leaving your F# codebase free of the deprecated API. ## Steps 1. Enumerate all F# callers: Use `atlas lsp findReferences ` to get AST-based references and `atlas grep "" src/**/*.fs` to catch dynamic or string-based usages across your F# codebase. 2. Create tracked work items: For each identified F# callsite, create a `todowrite` entry using `atlas todowrite add "Migrate : from to "`, ensuring every step is visible and accounted for. 3. Migrate each F# callsite: Apply changes using `atlas apply_patch `, which intelligently seeks the hunk's context and old lines in your `.fs` files, failing safely if the file has drifted. 4. Run affected F# tests: After each file modification, execute `atlas bash "dotnet test --project MyTests.fsproj"` to run your `Expecto` tests, verifying the change immediately. Mark the `todowrite` entry complete only upon test pass. 5. Format F# files: Ensure code consistency by running `atlas bash "dotnet fantomas "` over the modified F# source files. 6. Confirm zero remaining calls: Conclude the migration by running `atlas grep "" src/**/*.fs` to verify that no instances of the deprecated F# symbol remain in your codebase. 7. Delete old F# implementation: Once confirmed, remove the deprecated F# function or module implementation (e.g., `rm src/MyProject/DeprecatedModule.fs`). ## FAQ ### How does Atlas handle F# specific constructs like discriminated unions during migration? Atlas indexes F# code by AST declarations using tree-sitter, allowing it to understand constructs like discriminated unions, modules, and computation expressions. This enables precise targeting of deprecated symbols within F# idioms. ### Can Atlas run my existing F# Expecto tests after a migration? Yes, Atlas uses the `bash` tool to execute your F# test runner. It can run `dotnet test --project MyTests.fsproj` (which supports Expecto) after each file modification, ensuring immediate verification of changes. ### What if a F# file changes while Atlas is working on it? Atlas's `apply_patch` tool is designed to fail rather than misapply. It seeks the hunk's context and old lines, throwing "Failed to find expected lines" if the file has drifted, preventing incorrect modifications to your F# code. ### How does Atlas ensure all F# call sites are found, even dynamic ones? Atlas combines the `lsp` tool's `findReferences` for AST-based symbol resolution with `grep` for dynamic or string-based usages. This hybrid approach ensures a complete enumeration of all F# call sites, including those not directly linked by the language server. ### Does Atlas modify my F# code without my approval? No. Atlas drafts a plan in a read-only plan agent and asks for approval before switching to a build agent. Every file edit generates a unified diff for your review, and all tool calls are permission-gated, giving you full control over F# code changes. ### How does Atlas handle F# code formatting after a migration? Atlas can run `fantomas` over changed `.fs` files using the `bash` tool. This ensures that all migrated F# code adheres to your project's formatting standards, maintaining consistency across the codebase. ### Can Atlas work with my F# solution's .fsproj file structure? Yes, Atlas is designed to run in a solution with an `.fsproj` file. It reads the file order from the project file, which is crucial for F# compilation, and uses this context to accurately index and modify your F# codebase. ### What if I need to roll back changes made by Atlas to my F# project? Atlas snapshots file changes as git patches, allowing edits to be diffed and rolled back easily. It also reads git branches, status, and diffs, and can stage and create commits on your behalf, providing robust version control integration for your F# project. --- Canonical HTML: https://runatlas.sh/resources/stacks/migrate-a-deprecated-api-across-callsites-in-fsharp Source of truth: aeo_pages row `/resources/stacks/migrate-a-deprecated-api-across-callsites-in-fsharp` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.