Looking at the Upgrade progress, it has passed the first SPContentDatabaseSequence(130/130) then it's 30% Complete after about 2 hours. Then it starts on SPContentDatabaseSequence2, and currently at 31.22 which it has been on for a long time. over 13 hours perhaps. In total it's been on for 20 hours now.

Our database is a rbs system With total size of 1.7 TB! Blob store is 1.6 TB of this.

Looking at the Upgrade log it's last entry was 15 hours ago, but there seems to be no errors at all so far, either in log or the Upgrade progress Window, just 14 warnings. The logging seems to come in jumps and hoops like after 2-3 hours it suddenly logs in a lot of stuff at once. Which makes me think maybe it's doing a huge import and won't log before it's done.

  • Do you see any errors? I think you have just to wait. Once I need to wait 2 hours for 1,5GB. How is the structure? (how many sites/web, hierarchy )
    – Nk SP
    May 22, 2015 at 6:58
  • "manage content databases" says it has 328 site Collections. But in trurth i think it's like 1 site Collection With a huge number of webs
    – Skruf
    May 22, 2015 at 7:03
  • 1
    Patience, patience.
    – Jussi Palo
    May 22, 2015 at 7:04
  • If the structure is complex (in hierarchical way) it will take a lot of time. Btw pls check the upgrade and farm logs
    – Nk SP
    May 22, 2015 at 7:08
  • Checked logs, looks like the initial upgradelog of 1st sequence did some change/update for every web, looks to be over 1000 webs at least.
    – Skruf
    May 22, 2015 at 7:28

2 Answers 2


From your questions and comment, I understand you have a content Db with size of 1.7 TB along 328 Site collections. This is big content DB and it will take too much time, if you are not seeing any error then you have to wait.

As a side note, I would highly recommend that split the database into multiple DBs. As per Best practice your db should be around 250GB for smooth operation. You can move out the site collection from main DB to others. you can use Move-spsite command.

Once you have smaller DBs then it is easy to upgrade them and you can run multiple upgrade at a same time.


I just got through a migration from SP2007 to SP2010 to SP2013.

Here's a few tips:

1) The recommended max size for a content DB on an average SQL DB Server is no more than 200 GB. If you're over, it may work, but expect it to take a long time.

a. Definitely consider splitting your content database up into smaller ones if it is larger than 200 GB. Each site collection should probably have its own content database. If you have one massive site collection, you will need to look at a way to split them up.

I've seen the web backup and restore method to a site collection with the same base site template and even a suggestion to copy the site collection and delete portions of it on one copy. Haven't tried those methods out yet to verify they work myself. However, I'm thinking about splitting up some content dbs I have that are well over 200 Gigabytes.

During my migration, the largest database migrated was 400 GB and it took several tries. On the final successful try, it took a few hours to run.

If you have smaller content databases, migrate your smaller content databases first. You can probably do up to three simultaneously from different powershell prompt windows with little issue if the databases are under 100 GigaBytes.

2) The percentage complete indicator provides no indication of how much time it will take to complete. For larger content databases, the percentage complete will tend to sit there and it will appear that your migration is stuck. However, there are ways to check whether it is really stuck.

a. The logs: c:\program files\common files\microsoft shared\web server extensions\14\logs (Substitute 14 with 15 for SP2013).

Unfortunately, when the migration script is busy running a script it stops writing to the logs for quite a while.

b. SQL Activity Monitor and SQL Profiler. These two tools that come with MS SQL 2012 and MS SQL 2014 are awesome for seeing what your migration is doing behind the scenes.

c. The migration script will run under the login name of the account that your command prompt or powershell prompt is running as, so you can filter for your user name.

d. From the SQL Activity Monitor, you'll be able to see all the processes that are connected to your SQL server. If you notice a lot of extraneous processes other than your Mount-SPContentDatabase, you probably should look at ways to reduce the connections to give more resources to the migration. Consider disabling the SP Timer service and IIS service while migrating. (Run a test on a smaller content db to see if migration works while these services are off to be sure.)

3) If possible you'll want to run your migration on an SQL server with plenty of RAM, CPUs, and HD space. When you upgrade a content database it will cause the db to grow and increase the size of you T-Log quite a bit. If you run out of HD space, your migration will fail or be corrupted.

a. Also note, that if you have a live SharePoint farm that you are trying to migrate to then your DB server is probably gonna be busy processing www requests. You can migrate your SharePoint databases to a standalone dedicated migration DB server if you have one. Mount-SPContentDatabase -Name [Name] -WebApplication [Url to web app] -DatabaseServer [DBServer]

4) Beware of any Host Intrusion Protection system (HIPS) or Antivirus programs running on your SQL server or front end server. Those programs could inadvertently sabotage your migration. HIPS kept blocking some of the migration script queries on my SQL server incorrectly thinking they were an SQL injection attack.

5) Definitely do a rehearsal run of a few of your databases before doing the full migration if you've got a lot of content databases to migrate over.

Hope this helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.