19 Questions to ask before migrating a Xamarin app to .NET MAUI

I got asked about helping rewrite a "legacy Xamarin-based mobile app to .NET MAUI". They'd already determined how long it would take, but had very few details about the app or the rewrite/migration.

To help anyone else in a similar situation, here are a few questions to ask (and get answered) to determine how much time/effort will be required in such a project.

1. What's driving the rewrite?
2. What's driving the time scale for the rewrite?
3. When was the code written initially?
4. Who has been maintaining and updating the app since it was originally written?
5. What does the existing app do?
6. How is the existing app built?
7. How is the existing app distributed?
8. How is the existing app tested?
9. Does the initial code base use Xamarin.Forms or Xamarin Native?
10. Which platforms (operating systems) does the existing app run on?
11. Does the application have any specific customisation or variation in functionality when running on different devices or operating systems?
12. What programming languages does the existing app use?
13. How large is the existing app?
14. What 3rd party controls or tools does the existing app use?
15. How are 3rd party tools licensed?
16. Do the 3rd party tools have equivalent support for .NET MAUI?
17. What external systems (including back-ends, analytics, etc.) does the existing app connect to?
18. Beyond getting the app to build and run with .NET MAUI, what other changes are planned and/or needed?
19. What are the long-term plans for the app? (Who's going to maintain and update it after this rewrite?)

Obviously, the answers to many of these questions will prompt follow-ups to identify relevant specifics.

What did I miss?

My second rule of testing

For a long time, I've told people that I recommend adding tests for any code that is "non-trivial".

I define non-trivial to mean any code that you can't look at and immediately see all the possible paths through it and potential outputs, such that you can see that all possible negative and edge-case consequences are correctly handled. Yes, the reality is that very little code meets this threshold.

I also make exceptions for plumbing code.

I now have a second rule. Well, guideline:

Include tests for anything that may be affected by a change in a dependency.

This matters because dependencies change and get updated. Without tests to verify that nothing has broken or been altered in unwanted ways, switching to using a new version of a dependency is a bigger risk than it should be or that you probably want to have to deal with.

Oh, that package you use now has a new version that reportedly fixes a security vulnerability. How quickly can you switch to using the new version? Do you trust that there are no other changes or consequences of updating? Can you be sure? Do you have the time to verify manually?

Also note that this applies to both internally and externally sourced dependencies.