We have planned to migrate our SharePoint server 2010 to SharePoint Online (Office 365). Before we migrate our production site, we have tried to create a test environment in SharePoint server 2010 using the backup data of our production sites. We have tried the below steps to create a Staging environment as like our Production environment. Can anyone suggest the steps for migration or the steps we have followed is good.
Steps :
I have backup the content database.
Created a new web application and restored the backup database to this web application.
As the site is not loading and hence we created a new site
collection.
Once the new site collection is created, the site is able to load but the site and content of production site is not restored as like in our testing site.
Will restoring the database is enough to restore the site collection in the application in SharePoint or need to restore the site separately to the web application. Any suggested solution will be grateful for me to proceed.
Thank you and Best Regards,
Ragunaathan M P
If you are creating a test environment to use for SharePoint online your best bet is to use the 2016 bits. When you move your content over you need to do make sure you have upgraded the content.
So you would do some flavor of the following:
1) Backup the existing database
2) Restore the DB to the new farm
3) Mount the DB (Mount-SPContentDatabase xxx)
At this point (this is very overly simplified you should be able to render the sites.
Lots of other factors will be involved (InfoPath, Full Trust Code, Workflows, etc). However if your content is pretty vanilla this is what I would do. Dp not use the nob2bsiteupgrade option on mount or you will have an upgraded database schema, but your sites won't work.
To validate your upgrade check the logs and look at the versions table in the database. You should see a 16.x.x.x version. The other numbers are the upgrader actions and won't tell you much.
Here are some references:
Upgrade Content
Upgrade-SPContentDatabase
Mount-SPContentDatabase
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
After building a protoype Sharepoint site for the client I am now looking to export it for the client's eyes.
I'm looking for the best solution for exporting, sharing or moving a Sharepoint 2013 site for the client to see on their server. The site is currently only on one server so no server farms are involved.
The site is built using Sharepoint 2013.
I've been running through this guide, but could anyopne clarify if this process creates a back-up of the entire site or just the database: http://technet.microsoft.com/en-us/library/ee428301(v=office.15).aspx
Any help would be greatly appreciated - Thanks!
There is a great video on how to do a backup and restore in SP10.
This does work for SP13 except the backup needs to be done with PowerShell.
How Do I: Backup and Restore a SharePoint 2010 Site Collection?
The backup and restore is not guaranteed to give you the exact result as some features could be activated and some CSS could change the look of the imported site.
We have a company SharePoint site that we paid a company to configure and setup for us. We are slowly taking over more and more of the administration of this site. We would like to setup a test environment so we can make changes with out affecting daily business.
How can we take what they have already installed, deployed, and configured and make a copy of it?
I know we can backup the database, but what about the stuff the downloaded and deployed into the system?
None of what they installed are paid applications from what i can tell. They look like the base applications from the Microsoft SharePoint site like Case Management, Knowledge Base, and a few others.
Thanks
You should take an inventory of the installed solutions, you can see that in the list of solutions under central administration. Then try to identity 3rd party solutions and get the WSP files (I bet they are stored in a folder on your server :))
Set up a new environment, make sure to install exactly the same version, including any service packs and/or hotfixes. You can get that list when you search for the version number in Google (the version number is usually seen in the Site Administration page).
After that, install your custom solutions and attach the content database, this should be it.
I need to migrate our SharePoint farm to a new domain. Until everything is moved we have full trust set up between the domains.
Farm Hardware
One WFE/Index Server
Two SQL DB Servers (clustered)
I know how to do this using all new hardware from production to a dev environment but doing an in place migration seems more daunting. To take some of the pressure off we have a new beefy SharePoint box to install to that will be a fresh box on the new domain but we don't have enough hardware to have a separate SQL cluster.
I am told that all the boxes should be on the same domain so now the hard part is to bring the SQL box on the new domain. Can I just switch domains on the SQL DB cluster and then install SP on the new WFE?
Voted to move to serverfault, but here's my 2 cents. Moving SQL Server 2 a new domain is easy, sql server will pick up any changes. The problem is sharepoint. SharePoint users to be exact.
Any documents in your site(s) will have it's created by / modified by broken, because even though the same users exist in the new domain, the bindings will be incorrect, sharepoint expects for instance user userA#olddomain.local, which is very different from user userA#newdomain.local. There is a way around this using httpmodules etc, but it is a pain in the ass.
Check out the result when googling migrate sharepoint new domain.
I've run a similar setup before. If they're full trust, you should be able to reconnect to your pre-existing config/content dbs from the new SharePoint instance in the new domain.
SQL server
You can have your SQL server in a different domain as long as there is a trust between the domains.
Migrating users
With regards to migrating your users, it's a daunting task because those user's SIDS own objects, I've used stsadm -o migrateuser but it's not terribly helpful, I'd consider looking into 3rd party software such as DocAve who have products that assist in migrating SharePoint content. If you really want to hack it, break open the Users table in your content databases and write a script to update the usernames and sids.
I'm in the process of moving a complete sharepoint install to a different server.
Can anyone tell me if it's possible to just move the existing Shared Services Provider rather than starting from scratch?
All the best
You really need to move the SSP in concert with everything else in the farm. The two things to move are 1. databases and 2. the file system.
A .doc file for moving all of the SharePoint databases has been published here. Microsoft will soon have an updated procedure for this published on TechNet, according to the To The SharePoint blog.
Then to cover off any file system changes, I would set up a clean install of SharePoint (if you didn't need to already by following the document mentioned above) and do a file comparison between your source and destination SharePoint application servers. I usually use WinMerge as its free but Beyond Compare is also good. Also check any custom solutions are deployed on your destination server.
By ensuring your databases are moved correctly and all of your files are in place you should be OK. Make sure you test every custom component on your destination server before erasing the source databases and files (even better, archive the source).
Yes, create a new SSP and move the applications.
How to on migration of applications here
For moving the SSP to a new farm
Or try the Microsoft SharePoint Administration ToolKit v2.0
For another view of this