There are a couple of alternatives you could try as you move along. I assume you don’t have an API to access a Data Access Layer – which would be the best and therefore my first option:

#Make a full blown web application

Switching back and forth between different types of application is not very useful and will probably ware down your users with agony and fear. My idea is instead to either make an API in the existing application so you can access the database from there. The other alternative is to access the database directly from the new web application. Which way you chose is, from a UX perspective, irrelevant. But working in one application isn’t. In fact it is quite crucial. Still – since you post this question here, I guess you already know that, and that you want the second best option, not quite as costly. That leads to contestant no 2:

#Control the web page - server side

I guess this is possible since you work in an ASP.NET environment (?) and that you user the attribute runat=”server” for the controls? If this is true you could use the same event when a user clicks a customer in the application, but you don’t open a new window. You use the same instance of the web browser and let the native application control what happens in the browser. This means that when user (in the native old app) clicks on customer B, the web page is reloaded with customer B instantly. No timing events and no “confirm” events needed.

But seriously consider option one, because in the long run it will be cheaper than what you’re currently doing. Maybe use a break-even cost analysis which shows that you will gain on the first approach in three years’ time.

There are a couple of alternatives you could try as you move along. I assume you don’t have an API to access a Data Access Layer – which would be the best and therefore my first option:

Make a full blown web application

Switching back and forth between different types of application is not very useful and will probably ware down your users with agony and fear. My idea is instead to either make an API in the existing application so you can access the database from there. The other alternative is to access the database directly from the new web application. Which way you chose is, from a UX perspective, irrelevant. But working in one application isn’t. In fact it is quite crucial. Still – since you post this question here, I guess you already know that, and that you want the second best option, not quite as costly. That leads to contestant no 2:

Control the web page - server side

I guess this is possible since you work in an ASP.NET environment (?) and that you user the attribute runat=”server” for the controls? If this is true you could use the same event when a user clicks a customer in the application, but you don’t open a new window. You use the same instance of the web browser and let the native application control what happens in the browser. This means that when user (in the native old app) clicks on customer B, the web page is reloaded with customer B instantly. No timing events and no “confirm” events needed.

But seriously consider option one, because in the long run it will be cheaper than what you’re currently doing. Maybe use a break-even cost analysis which shows that you will gain on the first approach in three years’ time.