Migrating to a hosted environment is very straightforward.
Preparation
Set timeline for the migration process, bringing in the necessary players (IT, networking, end users).
Determine data transfer mechanism (SendThisFile? FTP? Other?) and test.
VSys One: build out and publish client virtual servers, provide public IP addresses.
Client: Configure any outbound firewall rules.
Client: If using VSys Live or VSys Live Kiosk, switch DNS entries for this from explicit (numeric) IP addresses to CNAME, pointing to the client.hostedvsys.com names that you're assigned. This makes live switchover much faster, eliminates most TTL issues, and prevents last-minute problems with DNS permissions.
Client: Using an evaluation (sample) database, verify client connectivity to your environment.
Client: Provide the VSys One hosting team with:
Name and e-mail address for each of the end users.
Password policy requirements.
Migration
Typically a two to six hour process, depending on the size of the database.
Client: Remove access rights to both the current in-house test and production databases. It's important to prevent users from making any data changes.
Client: Back up current production SQL Server database and compress using WinZip or other effective compression tools.
Client: Transfer compressed data backup.
VSys One: Restore data backup.
VSys One: Verify application functionality to new database.
VSys One: Respond to any customer connectivity/access issues.
VSys Web
Customers using VSys Web need make no special changes: because VSys Web already resides on our servers, it will work the same after migrating VSys One to hosted as before.
VSys Live
VSys One and VSys Live must "live" in the same place, meaning that they cannot be in separate datacenters due to network latency issues. If you're using VSys Live and/or VSys Live Kiosk, these, too, will migrate to our servers along with VSys One. (In general they will live on a separate server than the VSys One desktop application.)
As long as you control your own DNS, your new VSys Live environment can retain the same name and use the same SSL certificates that are in use now.
VSys Live Kiosk
Like VSys Live, VSys Live Kiosk must also live in the same place as VSys One. VSys Live Kiosk is not always publicly-facing, though. If you want your VSys Live Kiosk to be private, i.e. the login keypad not even visible to the outside world, there are a few options:
Using HTTP "Basic" authentication, put a set of user IDs/passwords on the site. These are usually static and remembered by browsers on machines which are permitted to use the kiosk. (These are not individual user logins into the kiosk; those are the volunteer kiosk PINs.)
Firewall rules. If you provide the hosting team with a list or netmask of your organization's external IP addresses (those which would be used by machines inside of your network to reach the kiosk), we can permit only connections from those IP addresses to access it.
Site-to-site VPN. These are complex, and not normally used for this purpose, but if one is being established for LDAP authentication, one could be used in this way as well.