Well, the .ovpn config files simply point to the .crt, .key, and other files, so you'll need to replace those files with others of the same name and/or edit the .ovpn files to point to the new files.
You should also build new client certificates to replace the old ones, and do the same with clients.
This is a good opportunity to review your config files in general, since across the board changes to all clients using certificates are required - do you want to change the cipher, auth, or tls-cipher options, or perhaps make other changes?
Example:
If I have
...
ca oldCA.crt
cert oldclient763.crt
key oldclient763.key
ns-cert-type server
tls-auth oldta.key 1
cipher AES-128-CBC
auth SHA256
tls-cipher DHE-RSA-AES128-SHA
comp-lzo
...
Then I can either take the new CA.crt and name it "oldCA.crt", so when I put it in the same directory, the .ovpn doesn't need to change, or I can change the .ovpn and replace "ca oldCA.crt" with "ca newCA.crt", putting "newCA.crt" in place, i.e.
...
ca newCA.crt
cert newclient763.crt
key newclient763.key
ns-cert-type server
tls-auth newta.key 1
cipher AES-256-CBC
auth SHA512
tls-cipher DHE-RSA-AES256-SHA
comp-lzo
...
Note this second option has a distinct advantage - you can do the rollout in two phases. First, distribute newCA.crt, newta.key, the newclientXXX files to all client machines, _then_ distribute the new .ovpn files. If you name the .ovpn files something different also, you can have both available at once, so your client machines can easily use either old or new during a transition period, allowing the server to be updated and/or rolled back as required while not causing major disruption. After the new ones are validated, then the old ones should be deleted.
