You might look at Tasks, but ultimately that's probably not going to be the biggest issue.

If you run multiple simultaneous threads to get data, then each will have a connection. So, you'd be creating multiple connections to an Access database. That may or may not cause a problem. Access has not historically dealt all that well with multiple simultaneous connections because it locks more than it absolutely needs to, which can mean that one thread may block another till it's done, in which case you won't be gaining much from having multiple threads.

Another points is that the Load event may be too late. It may also be all you can do. If that's your startup form, you don't have a lot of good alternatives. If it isn't the startup form, then you have some flexibility, since you could move starting the BGW or the Tasks, or whatever route you take, into the constructor. The constructor is called when you create the form, while the Load event is called when you show the form. You can create the form a long time before you show it, so you might have the data being gathered in the background such that it is ready by the time you need it. Of course, that won't work if the form is your startup form such that there is no change of a delay prior to needing the form (unless you add a splash screen).