Articles in this section

See more

Read-Only Lock

Updated
Follow

Details

The Read-only lock should be removed on your source Site Collection before running a migration action with ShareGate Desktop. 

Some SharePoint services do not respond correctly when the Site Collection is on read-only mode  (even if they are only used to read information), and the requests will not be processed as intended.

Solution

You must remove the Read-only lock on your Site Collection before running your migration. You can do so by following the instructions outlined in this article. 

Not removing the read-only lock will mostly affect the structural parts of your environment, like Web Parts and Site settings, but the behavior is unpredictable and it may affect more overall.

ShareGate Desktop accesses SharePoint through multiple APIs and has to send many requests to the servers to obtain and resolve your data. Given the complexity of this operation, the read-only lock will often cause one of these calls to be unresolved, and ShareGate Desktop is unable to push the data properly. This results in errors, and some items may not copy properly.  

 

Comments

5 comments

Sort by Date Votes
  • Avatar
    Per Svedenbring

    We are going with AlwaysOn High Availability Groups and are having a problem. When the first SQL-server is primary it works. When we failover to the second we get this error in SharePoint:

    We apologize for any inconvenience, but we've made the site read only while we're making some improvements.

    It seems locked somehow. The database properties says Read-Only = False.

    I try some coding:

    $SiteURL = "https://siteXXX"
    $Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration($SiteURL)
    $Admin.ClearMaintenanceMode()

    or

    Set-SPSite -Identity "https://siteXXX" -LockState "Unlock"

    or 

    $site = get-spsite https://siteXXX

    $site.GetType().GetProperty("MaintenanceMode").GetSetMethod($true).Invoke($site, @($false));

    but Always get this error: "Failed to update database "SP_ContentDB_XXX" because the database is read-only.

    What is happening and any suggestion how to solve it? SharePoint 2016.

    0
    Comment actions Permalink
  • Avatar
    Alex

    Hello Per,

    Thank you for your comment. I'm going to go ahead and open a ticket with Support for you, they'll be better aligned to help you with this issue!

    Thanks. 

    0
    Comment actions Permalink
  • Avatar
    Abdulla Al-Mahmeed

    What is the alternative? We want to restrict users from changing site content during migration, and were planning to use the read-only lock to achieve that.

    So what is the best practice alternative for preventing users from adding content?

    1
    Comment actions Permalink
  • Avatar
    Vic (Edited )

    Hi BAPCO,

    From a technical standpoint, options are limited. Establishing a good communication plan with your users is usually the way to go.

    If you are migrating from an on-premises environment to another on-premises environment (SharePoint 2019 and below), it is possible to use DNS redirection to bring your users to the new site(s) while you are doing an incremental migration from the old site(s).

    You will have to modify your host file for ShareGate Desktop to work during that incremental migration.

    If this is your scenario and you think this solution can work for you, don't hesitate to reach out to our excellent support team for assistance.

    0
    Comment actions Permalink
  • Avatar
    Abdulla Al-Mahmeed

    Hi Vic,

    Thanks for the excellent answer. Our migration scenario is ON PREMISE SharePoint 2013 --> Office 365 SharePoint Online, so the DNS redirect trick probably won't work.

    I already asked the support team who suggested doing a cut-off incremental migration after the main migration is done. But I agree 100% that the biggest factor of success (given all circumstances) is a proper communication plan.

    Thanks again.

    1
    Comment actions Permalink

Please sign in to leave a comment.

Related articles