Absolutely feel your pain. Migrating a large PowerBuilder app can feel like defusing a bomb while blindfolded. I’ve been in your shoes, and believe me, you're not alone.

You’re trying to preserve business logic built over decades while modernizing it to survive in today’s .NET Core ecosystem. Hats off to you for even starting. That takes guts.

• Don’t lift-and-shift blindly. Some data windows and business logic might be reusable in a modern wrapper. Others? Not worth the effort. We made peace with rebuilding certain modules to avoid duct-taping legacy quirks into a modern stack.

• PFC components often sneak in deep dependencies and tight coupling. Audit what’s being used and find .NET Core equivalents where possible. Don't port the whole thing unless you have to—it’s like moving with all your childhood toys, broken and all.

• If you’re still using Informix, consider layering in an ORM like Entity Framework Core (with a custom provider or wrapping Informix ODBC calls). We built an abstraction layer early to keep the data access logic portable. Future-you will thank you.

• We partnered with a vendor who used a tool for the heavy lifting. The tool identifies reusable business logic, migrates UI components where possible, and even generates .NET-compatible equivalents for data windows. It reduced our manual work and helped avoid re-inventing every wheel.

• It also helped us visualize the architecture post-migration, which is something you’ll need when selling this effort to upper management.

• .NET Core apps don’t think the same way PowerBuilder does. Nested data windows, for instance, might kill performance if ported directly. We rewrote some screens to follow a cleaner MVVM pattern, which paid off big-time in maintainability.