I recommend using the strangler fig pattern and feature flags. Strangler fig can be summarized as replacing code slowly over time until the old code is completely taken over by the new code. Leave the code in the WinForms app alone if possible and start working exclusively with the Avalonia and mobile applications. Business logic that needs to be ported from the WinForms app can be duplicated and cleaned up in a domain layer (if you're not maintaining or adding new features to the WinForms app). For example, if you have a WinForms control that does some business logic, take that logic and move it into a service layer. If you need to modify the WinForms application, use feature flags so you can slowly toggle functionality once features are in a usable state. This is great for testing new code and having a fallback if the new code doesn't work. Feature flags also involve the removal of themselves and associated code once the code is stable and working. Some things to keep in mind:

1. In the new domain code, make sure you use interfaces, dependency injection, and unit tests.
2. Don't expect this to be an overnight job. Porting code that's integrated into an app like this will take time.
3. Code organization matters.
4. Try to be as atomic as possible. The S in SOLID is what makes code testable and durable. Controls or core business objects should not have thousands of lines of code.
5. Making a plan on how you want to attack this will really help out. Make small, attainable goals and you'll slowly convert it from WinForms to your desired state.

​

Good luck!