Happy to share my two cents, and obviously you have your own experience to weigh against. I mention this after reading my last comments- they sounded painfully preachy.
You do have a lot to think about. Your current model is tuned for growth by price, but you want to transition into a paid model. Rather than a freemium or ad based model, you are looking for a 3rd party with a larger customer base to help grow your user base and add an element of credibility through their established reputation. Presumably you and the company would either split the proceeds from each sale, or they would pay you for the license to use the source code of your current version to brand as their own, or some mixture of the two.
I'm not sure what your target price is for the app, but I could see the 3rd party paying you a yearly fee based on the size of their customer base, and you maintain control over everything, and in the agreement they specify that a certain number of promotional events are integrated with content in the app, and you'll have the dev resources dedicated for that work ahead of time.
Depending on how much customer data is integrated, the frequency of synching, the consequences for technical difficulties, etc, you probably don't want to go that route, and want as little control as possible, like none. If there's a problem, it will be connecting your app to that 3rd party, and you will never have the access to the 3rd party the way the 3rd party can have access to your source code.
I think questions of control over the roadmap, data isolation, and data security will be relatively easy to live with once you have an agreement and sense of the relationship. Much more difficult will be customer questions, because no matter what, customers are going to come to you for support, probably offering their PII unprompted, on matters you have no businesses discussing. Once or twice a day will be annoying. Multiply that as customer base grows and it could severely distract and demoralize your team.
The difficulty is pointing customers to the white label for all support questions without taking your name completely off the product ("Powered by XYZ"). People need to know that the 3rd party is using your tech. As part of the written agreement, provisions for training should be provided to call centers (and maybe tellers?) so that support questions are quickly routed to people who are familiar with the product: your team teaches their team, and their team escalates questions to their tech staff. One or two designated white label tech staff should be your only external contact for issues related to the white label product.
So, if prior to delivering the white label product, you could create a very delightful interface (like, 10x as delightful as that pig on Green Acres) for user flow through a support request, and focus on making support extremely easy to access from anywhere in the app, you will save yourselves much aggravation from users wanting you to help them integrate their Sep IRA with your app. If you can iterate on that focus of separation, you should be able to handle very quick growth. Your early training team can be your current staff, but you will need to dedicate more and more resources to the training and support cycle, ideally by overloading the training portion, as the white label user bases grow. Knowing what is coming down the road, you'll have the resources available when needed.
I'd like to see the app!