{"id":91,"date":"2026-09-20T08:38:03","date_gmt":"2026-09-20T08:38:03","guid":{"rendered":"https:\/\/microupdate.co.uk\/articles\/?p=91"},"modified":"2026-09-20T08:38:03","modified_gmt":"2026-09-20T08:38:03","slug":"wordpress-sorry-you-are-not-allowed-to-access-this-page-after-a-database-migration","status":"publish","type":"post","link":"https:\/\/microupdate.co.uk\/articles\/wordpress\/wordpress-sorry-you-are-not-allowed-to-access-this-page-after-a-database-migration\/","title":{"rendered":"WordPress: \u201cSorry, You Are Not Allowed to Access This Page\u201d After a Database Migration"},"content":{"rendered":"\n
\n
\n

After migrating a WordPress database to a new installation, you may find that WordPress accepts your username and password but then displays:<\/p>\n\n\n\n

\n

Sorry, you are not allowed to access this page.<\/p>\n<\/blockquote>\n\n\n\n

At first glance, this looks like a failed database migration, a permissions problem, or a damaged WordPress installation.<\/p>\n\n\n\n

In this case, the database migration was actually correct. The problem was caused by logging in with a WordPress user account that had deliberately been stripped of its Administrator permissions.<\/p>\n\n\n\n

The database was migrated using WP Migrate DB Pro<\/strong>, which is an excellent tool for moving WordPress databases between installations. As the investigation showed, WP Migrate DB Pro had correctly migrated the data, including changing the WordPress table prefix. The unexpected permissions were already present in the source database.<\/p>\n\n\n\n

This article shows the checks used to identify the problem and how to confirm whether the migration itself is at fault.<\/p>\n<\/div>\n\n\n\n

\n

The situation<\/h2>\n\n\n\n

The site database was migrated using WP Migrate DB Pro from a live WordPress site to an InstaWP staging site.<\/p>\n\n\n\n

The table prefix changed during the migration.<\/p>\n\n\n\n

For clarity, the actual prefixes used by the sites have been replaced in this article with:<\/p>\n\n\n\n

source_\ndestination_<\/code><\/pre>\n\n\n\n
The source site therefore used:<\/p>\n\n\n\n
source_<\/code><\/pre>\n\n\n\n
The destination site used:<\/p>\n\n\n\n
destination_<\/code><\/pre>\n\n\n\n
After the migration, WordPress accepted the login details but access to the WordPress Dashboard was denied with:<\/p>\n\n\n\n
Sorry, you are not allowed to access this page.<\/code><\/pre>\n\n\n\n
The first suspicion was that the migration had failed to transfer the WordPress user roles correctly.<\/p>\n<\/div>\n\n\n\n
\n
How WordPress stores user permissions<\/h2>\n\n\n\n
WordPress stores the role assigned to an individual user in the usermeta<\/code> table.<\/p>\n\n\n\n
Two important entries are:<\/p>\n\n\n\n
PREFIX_capabilities\nPREFIX_user_level<\/code><\/pre>\n\n\n\n
For example, on the destination site an Administrator would normally have:<\/p>\n\n\n\n
destination_capabilities\na:1:{s:13:\"administrator\";b:1;}<\/code><\/pre>\n\n\n\n
and:<\/p>\n\n\n\n
destination_user_level\n10<\/code><\/pre>\n\n\n\n
If instead the values are:<\/p>\n\n\n\n
destination_capabilities\na:0:{}\n\ndestination_user_level\n0<\/code><\/pre>\n\n\n\n
the user has no assigned WordPress role and no administrative privileges.<\/p>\n\n\n\n
They may still be able to authenticate, but they cannot access the WordPress administration area.<\/p>\n<\/div>\n\n\n\n
\n
Step 1: Check the affected user<\/h2>\n\n\n\n
The first check was against the migrated destination database.<\/p>\n\n\n\n
SELECT meta_key, meta_value\nFROM destination_usermeta\nWHERE user_id = 1\nAND (\n    meta_key LIKE '%capabilities'\n    OR meta_key LIKE '%user_level'\n);<\/code><\/pre>\n\n\n\n
The result was:<\/p>\n\n\n\n
meta_key<\/th>meta_value<\/th><\/tr><\/thead>
destination_capabilities<\/td>a:0:{}<\/td><\/tr>
destination_user_level<\/td>0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
This initially appeared to show that the migration had removed the Administrator role.<\/p>\n\n\n\n
However, that was not enough evidence to conclude that the migration was responsible.<\/p>\n<\/div>\n\n\n\n
\n
Step 2: Check the WordPress role definitions<\/h2>\n\n\n\n
WordPress also stores the available site roles in the options<\/code> table.<\/p>\n\n\n\n
The relevant option is:<\/p>\n\n\n\n
PREFIX_user_roles<\/code><\/pre>\n\n\n\n
This can be checked with:<\/p>\n\n\n\n
SELECT option_name, option_value\nFROM destination_options\nWHERE option_name = 'destination_user_roles';<\/code><\/pre>\n\n\n\n
The result showed that the normal WordPress roles were present, including:<\/p>\n\n\n\n
    \n
  • Administrator<\/li>\n\n\n\n
  • Editor<\/li>\n\n\n\n
  • Author<\/li>\n\n\n\n
  • Contributor<\/li>\n\n\n\n
  • Subscriber<\/li>\n<\/ul>\n\n\n\n
    The Administrator role also contained the expected administrative capabilities.<\/p>\n\n\n\n
    This confirmed that the site’s role definitions themselves had survived the migration.<\/p>\n\n\n\n
    The problem was limited to the role assigned to the individual user.<\/p>\n<\/div>\n\n\n\n
    \n
    Step 3: Compare the source database<\/h2>\n\n\n\n
    The next step was to check the same user on the live source site.<\/p>\n\n\n\n
    The source database used the prefix:<\/p>\n\n\n\n
    source_<\/code><\/pre>\n\n\n\n
    The query was:<\/p>\n\n\n\n
    SELECT meta_key, meta_value\nFROM source_usermeta\nWHERE user_id = 1\nAND (\n    meta_key LIKE '%capabilities'\n    OR meta_key LIKE '%user_level'\n);<\/code><\/pre>\n\n\n\n
    The result was:<\/p>\n\n\n\n
    meta_key<\/th>meta_value<\/th><\/tr><\/thead>
    source_capabilities<\/td>a:0:{}<\/td><\/tr>
    source_user_level<\/td>0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    This changed the diagnosis completely.<\/p>\n\n\n\n
    WP Migrate DB Pro had not removed the permissions.<\/p>\n\n\n\n
    The source database already contained those values.<\/p>\n\n\n\n
    WP Migrate DB Pro had correctly changed:<\/p>\n\n\n\n
    source_capabilities<\/code><\/pre>\n\n\n\n
    to:<\/p>\n\n\n\n
    destination_capabilities<\/code><\/pre>\n\n\n\n
    while preserving the value:<\/p>\n\n\n\n
    a:0:{}<\/code><\/pre>\n\n\n\n
    Likewise:<\/p>\n\n\n\n
    source_user_level = 0<\/code><\/pre>\n\n\n\n
    had correctly become:<\/p>\n\n\n\n
    destination_user_level = 0<\/code><\/pre>\n\n\n\n
    The migration was behaving correctly.<\/p>\n<\/div>\n\n\n\n
    \n
    Step 4: Check which WordPress user is really the Administrator<\/h2>\n\n\n\n
    The important next question was:<\/p>\n\n\n\n
    \n
    Was user ID 1 actually the current Administrator account?<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    To check the users:<\/p>\n\n\n\n
    SELECT ID, user_login, user_email\nFROM source_users\nORDER BY ID;<\/code><\/pre>\n\n\n\n
    This showed that user ID 1<\/code> was not the normal Administrator account.<\/p>\n\n\n\n
    User ID 2<\/code> was the active Administrator.<\/p>\n\n\n\n
    The capabilities for user ID 2<\/code> were then checked:<\/p>\n\n\n\n
    SELECT meta_key, meta_value\nFROM source_usermeta\nWHERE user_id = 2\nAND (\n    meta_key LIKE '%capabilities'\n    OR meta_key LIKE '%user_level'\n);<\/code><\/pre>\n\n\n\n
    The Administrator account contained the expected values:<\/p>\n\n\n\n
    source_capabilities\na:1:{s:13:\"administrator\";b:1;}\n\nsource_user_level\n10<\/code><\/pre>\n\n\n\n
    The migrated destination database could then be checked in exactly the same way:<\/p>\n\n\n\n
    SELECT meta_key, meta_value\nFROM destination_usermeta\nWHERE user_id = 2\nAND (\n    meta_key LIKE '%capabilities'\n    OR meta_key LIKE '%user_level'\n);<\/code><\/pre>\n\n\n\n
    The result contained:<\/p>\n\n\n\n
    destination_capabilities\na:1:{s:13:\"administrator\";b:1;}\n\ndestination_user_level\n10<\/code><\/pre>\n\n\n\n
    This confirmed that the Administrator permissions had migrated correctly.<\/p>\n<\/div>\n\n\n\n
    \n
    What had actually happened?<\/h2>\n\n\n\n
    User ID 1<\/code> had previously been deliberately downgraded on the live site.<\/p>\n\n\n\n
    This can be a useful security measure on an older WordPress installation where the first account is no longer used for administration.<\/p>\n\n\n\n
    Automated attacks commonly try obvious usernames and historic Administrator accounts.<\/p>\n\n\n\n
    Rather than deleting the account, its WordPress permissions had been removed.<\/p>\n\n\n\n
    Its database values were therefore:<\/p>\n\n\n\n
    capabilities = a:0:{}\nuser_level = 0<\/code><\/pre>\n\n\n\n
    WP Migrate DB Pro faithfully copied those values to the staging site and changed the prefix to match the destination installation.<\/p>\n\n\n\n
    The error occurred because that disabled account was then used to log into the newly migrated installation.<\/p>\n<\/div>\n\n\n\n
    \n
    The solution<\/h2>\n\n\n\n
    The correct solution was not to repair the database or recreate the WordPress roles.<\/p>\n\n\n\n
    It was simply to use the real Administrator account, which in this case was user ID 2<\/code>.<\/p>\n\n\n\n
    The migrated Administrator account retained:<\/p>\n\n\n\n
    capabilities = a:1:{s:13:\"administrator\";b:1;}\nuser_level = 10<\/code><\/pre>\n\n\n\n
    The staging site could therefore be accessed normally using that account.<\/p>\n<\/div>\n\n\n\n
    \n
    Keeping user ID 1 downgraded<\/h2>\n\n\n\n
    If user ID 1<\/code> has intentionally been disabled on the source site, the same configuration should normally be retained on the staging site.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    UPDATE destination_usermeta\nSET meta_value = 'a:0:{}'\nWHERE user_id = 1\nAND meta_key = 'destination_capabilities';\n\nUPDATE destination_usermeta\nSET meta_value = '0'\nWHERE user_id = 1\nAND meta_key = 'destination_user_level';<\/code><\/pre>\n\n\n\n
    This leaves the account present but without WordPress privileges.<\/p>\n\n\n\n
    The account should still have a strong password because it remains a valid WordPress user record.<\/p>\n<\/div>\n\n\n\n
    \n
    Useful diagnostic queries<\/h2>\n\n\n\n
    List all WordPress users<\/h3>\n\n\n\n
    SELECT ID, user_login, user_email\nFROM destination_users\nORDER BY ID;<\/code><\/pre>\n\n\n\n
    Replace destination_<\/code> with the actual table prefix for the site being checked.<\/p>\n\n\n\n
    Check the role assigned to one user<\/h3>\n\n\n\n
    SELECT meta_key, meta_value\nFROM destination_usermeta\nWHERE user_id = 2\nAND (\n    meta_key LIKE '%capabilities'\n    OR meta_key LIKE '%user_level'\n);<\/code><\/pre>\n\n\n\n
    Check the available WordPress roles<\/h3>\n\n\n\n
    SELECT option_name, option_value\nFROM destination_options\nWHERE option_name LIKE '%user_roles';<\/code><\/pre>\n\n\n\n
    Look for user metadata from an old table prefix<\/h3>\n\n\n\n
    If the site has previously used another WordPress prefix, it can also be useful to search more broadly:<\/p>\n\n\n\n
    SELECT meta_key, meta_value\nFROM destination_usermeta\nWHERE user_id = 1\nAND (\n    meta_key LIKE '%capabilities%'\n    OR meta_key LIKE '%user_level%'\n);<\/code><\/pre>\n\n\n\n
    This can reveal old entries such as:<\/p>\n\n\n\n
    oldprefix_capabilities\noldprefix_user_level\ndestination_capabilities\ndestination_user_level<\/code><\/pre>\n<\/div>\n\n\n\n
    \n
    What this demonstrates<\/h2>\n\n\n\n
    The message:<\/p>\n\n\n\n
    Sorry, you are not allowed to access this page.<\/code><\/pre>\n\n\n\n
    does not necessarily mean that WordPress is broken.<\/p>\n\n\n\n
    It often means that WordPress has successfully authenticated the user but that the account does not have permission to access the requested administration page.<\/p>\n\n\n\n
    After a database migration, check the following before changing anything:<\/p>\n\n\n\n
      \n
    1. Confirm which WordPress user you are actually logging in with.<\/li>\n\n\n\n
    2. Check that user’s capabilities<\/code> value.<\/li>\n\n\n\n
    3. Check its user_level<\/code>.<\/li>\n\n\n\n
    4. Confirm that the site’s user_roles<\/code> option exists.<\/li>\n\n\n\n
    5. Compare the same user against the source database.<\/li>\n\n\n\n
    6. Confirm that the table prefix was changed correctly.<\/li>\n\n\n\n
    7. Check another known Administrator account before assuming the migration failed.<\/li>\n<\/ol>\n\n\n\n
      The most important lesson from this particular case was simple:<\/p>\n\n\n\n
      \n
      Always compare the migrated database with the source before repairing anything.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
      The suspicious-looking values in the staging database were not corruption. They were an exact copy of the security configuration already present on the live site.<\/p>\n\n\n\n
      In this case, WP Migrate DB Pro had done exactly what it should. It migrated the database correctly, updated the prefix references, and preserved the existing user permissions. The troubleshooting process confirmed that the apparent migration problem was actually an intentionally restricted WordPress user account.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
      WordPress: \u201cSorry, You Are Not Allowed to Access This Page\u201d After a Database Migration<\/p>\n","protected":false},"author":1,"featured_media":93,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[12,6],"tags":[],"class_list":["post-91","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-migration","category-wordpress"],"_links":{"self":[{"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/posts\/91","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/comments?post=91"}],"version-history":[{"count":2,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/posts\/91\/revisions"}],"predecessor-version":[{"id":94,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/posts\/91\/revisions\/94"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/media\/93"}],"wp:attachment":[{"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/media?parent=91"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/categories?post=91"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/microupdate.co.uk\/articles\/wp-json\/wp\/v2\/tags?post=91"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}