I'm going to address this part:
I am fairly new to EE so any help is much appreciated.
I think you'll find that many of the developers here are currently using a workflow that incorporates version control, typically Git via Github or another service.
In most cases, our workflow looks like this:
- We start development on a local computer, with our database and site files there. As mentioned in another response, we use FocusLab's approach to config files to keep the site portable: Providing the database variables are updated or kept the same, we should be able to move things around without impact.
- When client review starts, we set up a Staging subdomain on one of our servers: Something like clientname.clearbold.com. We set up a database on that server with the same name & username/password as we had in dev, so no changes to the database config are needed. This sounds like the dev site on your live server.
- We'll dump a copy of the database in dev into a directory in our version-controlled project directory, and push it to our git repository. We use a deployment tool (Beanstalk or DeployHQ are good options) to (S)FTP all the files to the server. You can also log into your git repo on the server and pull down the files.
- We then import the database on Staging, and the site's running.
Now, once we get to the point where the client is making edits, whether to Staging if we're pre-launch or on Production if we've launched, that database is now the master. Any time we do development, we log onto the server the client is using, do a database dump, and copy that down to our dev machines. We import that locally to work with the latest content/data, and we include that dump file in our git repo so that all developers can get it. If the Production site is the master, we may want to update Staging with that dump so we can demo some new features there. This is really important. For us, the database is always a one-way update. We add new fields or install new add-ons in the master database, and then copy it down to dev to start working with it.
In your case, I'd recommend:
- Updating your config to use the FocusLab approach, so that you can copy your files into the live site directory without changing paths. This will also enable you to copy the site locally in the future to test updates/upgrades, develop new features, etc.
- It's fine to keep your current "dev" (more accurately, Staging, because the client can see it) site pointing to the same database. Since I've advocated always making modifications in the master database first, there's no need to copy from Production to Staging. Just be careful if you're testing new features via your Staging site.
- Be sure to make backups of your db before making any changes.
Virtual Servers, whether running Plesk like MediaTemple's DV or barebones like their VE, or any of EngineHosting's offerings, etc should let you enable and log in with SSH. I highly recommend getting the hang of this. Running mysqldump and mysql import from the command line are much, much more efficient than using PHPMyAdmin. (We run Rackspace Cloud and A Small Orange servers currently.)
I actually did a video of this workflow, using git and moving database dumps around, a while back: