Currently we are subscribed to GoDaddy for their dedicated server lease, and now we are considering just purchasing our own server and just moving off of GoDaddy.
I have no idea how to put all of my source code from one server to another and also move the database and other files. Please explain what process has to be followed for this.
Also wanted to ask if their would be any changed for the third party tools i have used in my application?
To migrate my web application from one server to another I would do following :
Make a list of all transferable which would be:
Latest and running Source code on the server (ideally located in wwwroot)
database back up files (usually .mdb or .bak)
Copy source code and database back up to targeted server. Obviously depending upon type of the server you may need to set up the site in IIS and and point it to new directory
Restore database backup on database server
edit web.config to point to new database server and credentials.
Another important tip: If you have kept domain name with GoDaddy and only changing hosting server you may also need to change namedserver of you domain, without which you will not be able to point your domain to new hosting provider!
You may not succeed on the very first attempt of copying your stuffs to target server. It's always better to maintain back up so that you can copy files again and again in case something goes wrong on the new server.
As long as third party charges are concerned please check with your service providers they may be able to guide you best. For above simple stuff you do not need to worry about license stuff.
All the best!
Related
This question has been asked before and I've spent two days chewing through it all, to no avail. I've worked in and around DNN since the very early days (anyone remember the IBuySpy portal from 20 years ago?), and I've migrated more than a dozen sites, all without issue. But in this case, I'm getting the old "object reference not set to..." The EventLog indicates an error in InitializePage but not much more to go on. The logs in the DNN _default folder are for some reason not populating; will check this.
The specifics: DNN 5.03.01 site, has worked fine for a client for years. Needs to be moved to a new server. Different domain name for testing, then we'll redirect the live domain name. Site has a default portal at Portals/0 (no longer used); client's portal is at Portals/1. DB is on same box, MS SQL Server.
What I did: created a Portal Alias in the old, live site to reflect the "test" domain name. Copied all file system content. Duped schema to new DB (same version of MS SQL Server), used Schema Compare to make sure it worked, added all data, used Data Compare to make sure it was all there. Logged into new DB using SMSS; works fine. On the new/test DB, disabled all entries in the WebServers table. Verified new portal alias exists, referencing Portals/1. Verified domain name is live with correct new IP. Set up new site on IIS using that IP, referencing Portals/1. Edited connectionstrings and appsettings entries in Web.config, using the credentials that worked with SMSS. Ran the new site by entering the new/test domain name. I also set the permissions broadly on the DNN folder.
Got: [new domain name]/Default.aspx?error=Object+reference+not+set+to+an+instance+of+an+object.&content=0
So I'm getting to the DNN folder on the new server, but it seems something's not right with PortalSettings (guessing here). Maybe it's going to Portal 0 (the defunct one). This shouldn't happen if I create the new PortalAlias before migrating.
Possible complicating factor: The new server contains another complete instance of DNN which handles the live version (a copy) of the Portals/0 portal on the old machine.
Anybody have any thoughts? Something I overlooked? How can I make absolutely certain I'm hitting the database?
In the older versions of DNN there was a PortalSetting value for DefaultPortalAlias. If that was set to something different it is possible you could see similar behavior.
Also, that version of DNN does not log entries to the /portals/_default/logs directory
I've successfully created site using Umbraco now its time to upload it on hosting server..
i've searched and got one paid product for the same..and i dont want to use it.
Has any body tried developing Umbraco site on local and then uploading it on server?
If yes then please help me doing that.
First I run the umbraco install from a local IIS website. Then I setup my visual studio solution for that website (and my souce control). Then I work, until I reach a beta version, then I go through this process for deploying:
Ftp over to the remove website and copy the whole website (I actually use Beyond compare).
Connect to my local database with management studio and create a .bak file.
Upload the .bak file to the database server.
Restore that database
Review connection strings in web.config
Then I'm pretty much done.
Once I'm "live" and have content I don't want to lose, when I want to work on the website, I bring back the live database through a .bak file, then I make my changes. They often include DB changes since the schema is basically in the database. I note all the operations I do. Once my changes are ready I manually replicate the changes on the live site as I update the files.
This is very painfull but I tried solutions like courrier and other things like that and they are not reliable enough for production I find. Manually is the only risk free way I see for the moment.
Hope this helps.
Yes, that happens all the time. Use FTP to copy your local installation to your webserver, modify the web.config to point to the correct database and your website should be up-and-running.
I'm sure there are more elegant solutions with less clicks but here's how I do it on azure websites with sql, not sure what hosting/db you're using:
1) Create an empty db on azure with the same login and user as my local db.
2) Create an empty site on azure connected to my db.
3) Download the publishing profile.
4) Upload the db the first time with Sql Azure Migration Wizard.
5) Import the publishing profile into and upload the site with WebMatrix.
6) Thereafter I deploy the site and db with WebMatrix.
WebMatrix uses WebDeploy or FTP, you can use WebDeploy through IIS if you like, and FTP.
I've got a DotNetNuke system (v 5.6) that's hosting several different portals, and I'd like to move one of them to another hosting provider. What's the easiest way to do this?
Every web site I find that claims to explain how to move a DotNetNuke site essentially says "Copy the entire database over to the new system." That's great if you've only got one portal in the database, but I've got a dozen of them. I only want to move one portal, not all of them.
Exporting the site to a .template is another popular suggestion. This exports the structure of the site (all the tab definitions, for example), but it doesn't include any of the actual HTML content. As such, that's essentially worthless.
There must be a reasonable way to do this short of trying to strip one individual portals data out of every single DNN table. Right?
When you export a site template, you can include the content of the site, as well (for the modules that support portability, which includes the standard HTML module). This is how the default site template has all of its content. When you do this, there will be a .template.resources file that you'll need, as well as the .template file.
The other option is to do a full backup and restore, and then remove the other sites once you've restored. If you have significant content in a module that doesn't support portability, I think this will be your best bet.
FYI, I did find a solution from someone over on the DotNetNuke forums.
Create a 2nd version of that install, then delete all the other
portals. Move the install with the one portal. We've done this several
times with installs with lots of portals and it works just fine. Yeah
there's still some noise left in the db, but it's a quick and
effective way of doing things.
Edit note that this will give you an install with 1 portal. You can't detach a portal from one install and reattach it to an existing
install (well, you can, but basically you have to export the portal as
a template and that isn't 100%)
This is the approach I took, and sure enough, it works.
In a nutshell:
Mirror the files for the web site to another server.
Mirror the DNN database to another server.
Log in a Host on the new setup and delete all the portals but the one you want to migrate.
Delete any module definitions that are not in use by the remaining portal.
Open up your favorite SQL tool and delete any entries in the Users and UserProfile tables that no longer have a matching row in the UserPortals table. DNN does not remove these by default, which is frustrating.
Hop in to Windows Explorer and delete all of the Portal folders you no longer need (ie: /Portal/1, /Portal/2, etc.)
Back up the database using Enterprise Manager to create a .bak file
Make a .zip of the entire DNN installation folder.
You now have a .bak that contains the database and a .zip that contains the files. Send those off to the new hosting company, and you should be all set. Just make sure to update your web.config to set the connection string properly to point to the new database server at the new hosting company.
It's just that easy. ;)
I have about 5 sites where till date all development changes have happened directly on the live server, where the change would be made on a test file first and if ok, would replace it with the original file.
However, I can't really continue with this approach now because the site has become quite complex and testing changes usually involves changes to DB as well. I will also be having some outsourced developers working on the site. So now need to figure out how to set up an environment such that the dev. team can make changes to a test environment running perhaps on the same server, as a subdomain on the main domain perhaps, but not sure how to go about it.
Our sites are hosted on a single dedicated server with WHM/Cpanel setup. Now,
a) how do I go about creating a staging environment where they have access to the latest files and a db copy of the live db?
b) how do I track what all files they've changed/updated, so that I can then copy them to the live server and upload?
Is there some other approach I can/should consider? Am not really sure how to go about this.
I work on quite a few DotNetNuke sites, and occasionally (I haven't figured out the common factor yet), when I use the Database Publishing Wizard from Microsoft to create scripts for the site I've created on my Dev server, after running the scripts at the host (usually GoDaddy.com), and uploading the site files, I get an error... I'm 99.9% sure that it's not file related, so not sure where to begin in the DB. Unfortunately with DotNetNuke you don't get the YSOD, but a generic error, with no real way to find the actual exception that has occured.
I'm just curious if anyone has had similar deployment issues using the Database Publishing Wizard, and if so, how they overcame them? I own the RedGate toolset, but some hosts like GoDaddy don't allow you to direct connect to their servers...
The Database Publishing Wizard's generated scripts usually need to be tweaked since it sometimes gets the order wrong of table/procedure creation when dealing with constraints. What I do is first backup the database, then run the script, and if I get an error, I move that query to the end of the script. Continue restoring the database and running the script until it works.
There are two areas that I would look at -
Are you running in the dbo schema and was your scripted database
using dbo?
Are you using an objectqualifier in either your dev or your
production environment? (look at your sqldataprovider configuration
settings)
You should be able to expose the underlying error message by setting the following in the web.config:
customErrors mode="Off"
Could you elaborate on "and uploading the site files"? New instance of DNN? updating an existing site? upgrading DNN version? If upgrade or update -- what files are you adding/overwriting?
Also, when using GoDaddy, can you check to verify that the web site's identity (network service or asp.net machine account depending on your IIS version) has sufficient permissions to the website's file system? It should have modify permissions and these may need to be reapplied if you are overwriting files.
IIS6 (XP, Server 2000, 2003) = ASP.Net Machine Account
IIS7 (Vista, Server 2008) = Network Service
Test your generated scripts on a new local database (using the free SQL Express product or the full meal deal). If it runs fine locally, then you can be confident that it will run elsewhere, all things being equal.
If it bombs when you run it locally, use the process of elimination and work your way through the script execution to find the offending code.
My hunch is that the order of scripts could be off. I think I've had that happen before with the database publishing wizard.
Just read your follow up. In every case that I've had your problem, it was always something to do with the connection string in web.config. Even after hours of staring at it, it was always a connection string issue in web.config. Get up, take a walk and then come back.
If you are getting one of DNN's error pages, there is a chance it may have logged the error to the eventlog table.
Depending on exactly what is happening and what DNN is showing you you might be able to manually look inside the EventLog table, pull out the XML data stored there, and parse it to find the stack trace and detailed information regarding the specific error at hand.
I have found however though that I get MUCH better overall experiences with deployments using backups and restores of my database, that way I am 100% sure that all objects moved correctly, and honestly it works better in my experience.
With GoDaddy I know another MAJOR common issue is incorrect file permissions, preventing DNN from modifying the web.config and other files that it needs to do.