A Beginner’s Guide to Managed WordPress

Thank you for choosing Managed WordPress at Liquid Web! We hope this guide will help you get started in making the most of your experience with the Managed WordPress Portal. There are some great features in the portal, and we’ve worked hard to make sure site maintenance is a cinch.

 

Quickly Jump To A Subject By Clicking its Link:

Login to MWP Portal and the WordPress Backend
Forgotten Password
Add a User to the MWP Portal
Granting SFTP Access
Migrate a Site
Create a New Site
Taking a Site Live
Managing DNS
Backups

 

Login to MWP Portal and the WordPress Backend

The fastest and easiest way to log into the Managed WordPress Portal is to first log in to your Liquid Web account at https://manage.liquidweb.com.

Once logged in you will see that you are on the Overview page. Here you will see your Managed WordPress server. Just click the plus sign next to that server to reveal the LOGIN button and click it.

Hint:
The Managed WordPress Portal uses the same credentials as your Liquid Web account so once logged into Liquid Web click the login button.

Liquid Web's WordPress control panel reveals how to login.

Once logged into the Managed WordPress Portal you will see the Welcome Screen which will ask you for a nickname and an email address to create your first site. Just be sure to follow the guidelines on what characters you can or cannot use in a nickname.

When the site is finished deploying, the portal will now show one default WordPress installation that you can work with pictured below. This WordPress instllation is called MyNewSite.You can simply click on the WP-Admin button, and that will take you directly to the WordPress login page for the new default site.Alternatively, click the blue link and append the default site URL with /wp-login.php.  In the above example this would be: https://mynewsite.m9n7y4ka-liquidwebsites.com/wp-login.php

When you create a new site in Managed WordPress Portal, you will be emailed an administrative user and password so you can access the site right away. It is recommended that you login and change the password immediately for security reasons.

 

Forgotten Password

If you forget your password, you can always access the login page and click on the “Lost Your Password” link under the login area. Clicking that link will send an email used to create the new default site, allowing you to change your password.

Click on the "Lost Password?" link to retreive WordPress Credentials.

As a best practice, you will always want to make sure you never use default usernames like “admin” or “user” or simple passwords (like English words) as they can be easily guessed using brute force methods. We have created some best practice for securing WordPress to help you add some extra security to your site.

 

Add a User to the MWP Portal

Since you will be working with different areas that can be confusing we’ll be using the following terminology to differentiate between them.

  1. Managed WordPress Portal – the custom control panel for your WordPress sites in Managed WordPress. The Portal is where you will add sites, work with those sites, access and adjust the setting for your websites. It’s also where you can find your backups!  The Portal will have a URL that begins with the word “app,” uses a custom string, and ends in “liquidwebsites.com” Example = https://app.m9n7y4ka-liquidwebsites.com/
  2. WordPress Dashboard – the traditional term for the back end of all WordPress sites. When you login into a specific WordPress site to perform maintenance on pages or plugins, you are accessing the WordPress Dashboard for that site.
  3. Liquid Web Account Management – this is the primary account area at Liquid Web where you log in to view all your products and services at Liquid Web, such as your invoices, your credit card payment, DNS zones, and other settings or tools that we provide for you.

You can add users to Managed WordPress Portal by logging into the Portal and then clicking on Users in the left menu. On that page, you will find a default “liquidweb_staff” user, used by our support staff, but feel free to add on any co-workers who need access to all the sites.

To add a new user click the blue Create User button to the far right.

Managed WordPress lets you add users to access sites.

Hint:
Any user you add to the Managed WordPress Portal area will be able to work with and make changes to ALL THE SITES including the ability to deleting sites from the portal.

If you want to restrict site access for a single team member, it’s best to create a WordPress Dashboard user (a WordPress user) allowing access only to that specific WordPress site.

Granting SFTP Access

If you wish only to give SFTP access to a team member (and not portal access or WordPress Dashboard access) you can provide the SFTP credentials to that team member.

  1. You can find those SFTP credentials by logging in to the portal and clicking on the blue Manage Site button for the specific site.Retrieve SFTP credentials in the Manage Site section.
  2. You will now find many portal tools and settings for that specific site. Scroll down the page until you come to the SFTP/SSH Credentials area. This area will initially provide the user, IP, and port information for accessing the site over SFTP.
  3. Click on the blue Generate New Password button.  When the popup window appears and asks, “Are you sure?” click the OK button.
  4. The page will refresh, revisit the SFTP/SSH Credentials area to find a new password was generated for that specific site.SFTP credentials are regenerated within the Manage Site section.

 

For your convenience, sse the blue COPY links to copy the information. When you are ready to revoke SFTP access for a team member access the SFTP/SSH Credentials area again and click the blue Generate New Password button to reset the password to something new.  Here are some things to know regarding SFTP.

  1. Passwords can be changed at any time.
  2. Each site in Managed WordPress portal only comes with one SFTP user and that username cannot be changed.

 

Migrate a Site

We have a custom plugin that will allow you to migrate any live, public-resolving site into Managed WordPress Portal.  You can find the plugin in the WordPress repository or even search it from a WordPress Dashboard on the Plugins page. The plugin is called Migrate to Liquid Web. This plugin was built with ease-of-use in mind and works great for anyone who wishes to migrate their own site.

Instructions for downloading and using the plugin are here:  https://www.liquidweb.com/kb/migrating-to-liquid-web-with-managed-wordpress-portal/

Some things to know about using this plugin are:

  1. Implement the migration plugin on the source, live site. It uses a push method, and thus, the source site must be publicly reachable by DNS. The plugin will not work on a local WordPress copy that is not openingly accessible through a URL.
  2. It can only push a copy of a site into our Managed WordPress and Managed WooCommerce product at Liquid Web. It is not compatible with migrating into other products at Liquid Web.
  3. It is not compatible with WordPress Multi-site (WordPress Multi-site is not compatible with our Managed WordPress solution). We can, however, break up a multi-site installation into individual sites and our team can then migrate each source site into their own, individual destination site on Managed WordPress Portal.

We are happy to perform a migration for you as well, even for multiple sites.  Here is how you can submit a request for a migration to have our team migrate a live site for you into Managed WordPress Portal:  https://www.liquidweb.com/kb/free-website-migration-service/

 

Create a New Site

To create a new site in Managed WordPress Portal simply log in to the portal and then click the Create New Site button in the upper right of the portal.

The portal will then ask you for a nickname for the site along with an email address.  Fill out both fields and then click the Create Site button.Create a WordPress site through a nickname.

It’ll take a minute or two to see the new site in the portal.  An email will shortly arrive with a username and password to access the WordPress Dashboard (also known as the WordPress backend) of the new site. Each WordPress site created in the portal installs with the default TwentySeventeen theme and comes fully prepared with its own SFTP/SSH credentials.

The email address used to install a new site is the same one used for important future updates to our portal, reports and other administrative WordPress tasks for that specific site.

With a new site deploys you’ll be provided a temporary URL to access the site.  The URL will include both the nickname of the site and the default temporary URL that is a part of your specific Managed WordPress Portal.

 

Taking a Site Live

When a site is migrated into Managed WordPress Portal it is copied to a temporary URL that is publicly resolvable over DNS. The temporary URL provides a means to test the functionality and before taking it live. This testing time provides an opportunity to get the site ready with all changes before it needs to be taken live with the real URL.

Two essential and sequential steps are necessary before publishing a site to the Internet.

  1. Change the  A record for the domain to the IP address within your Managed WordPress Portal. DNS does have to be taken care of first for the second step to work.
  2. Change the name in the Primary Domain field in the portal (under Site Details) from the temporary URL to the actual domain name.  That can be done by logging into the portal, clicking on Manage Site, and then find the Primary Domain field. Just replace the temporary URL with the straight domain name and click UPDATE.Taking a WordPress site live entails renaming the primary domain.

The portal will put the site into maintenance mode as it runs the update and gets the site ready to be live with the real domain name.The Managed WordPress Maintenance Page lets us know that updating is in progress.

Here are some things to note about the renaming process.

  1. DNS does have to resolve to the IP address of the server to deploy our automatic SSL (Secure Sockets Layer) application. Our SSL implementation runs a public DNS lookup to retrieve the IP address.
  2. The renaming process will automatically replace the temporary URLs in the database to ensure menus and image links will work with the real domain.
  3. If you wish for the site to resolve to the www version of the domain you will need to include that in the Primary Domain field in the portal.  In that case, you would set the primary domain field to www.domain.com instead of domain.com
  4. The site will be issued an automatic SSL during this process that will programmatically stay up to date!
  5. Once the renaming process has finished the portal will leave maintenance mode, and you will see the portal tools and features again for the site. At this point, the site will now be live on Managed WordPress Portal.

You can find more information documented on this here:  https://www.liquidweb.com/kb/going-live-site-managed-wordpress-portal/

 

Managing DNS

Many times customers wish to have Liquid Web host all their DNS records for a domain. You can do this by using Liquid Web’s name servers.You can use the following process to migrate all DNS records to Liquid Web:  https://www.liquidweb.com/kb/migrating-your-dns-to-liquid-web/

 

Backups

We know that backups are critical, so we provide those for you in Managed WordPress.Just click on Manage Site for the site you wish to work with and then click on Backups in the left menu.Backups are included in each Managed WordPress Product.

Here are a few apsects to note on our backups.

  1. Backups run nightly and are secured off-site location, so they don’t take up any space on the server where you sites live, meaning better performance for your websites.
  2. We keep 30 days of nightly backups, and while they are remote, you do have access to them on the Backups page.
  3. On the Backups page, you can manually create a new backup, download a backup from a specific date, or restore a backup from a particular time.
  4. If you choose to restore a backup from a specific date, it will restore right on top of the live site and revert the site to how it looked and operated on that date and time.

 

SQL Databases Migration with Command Line

What if you have dozens of SQL databases and manually backing up/restoring each database is too time-consuming for your project? No problem! We can script out a method that will export and import all databases at once without needing manual intervention. For help with transferring SQL Logins and Stored Procedures & Views take a look at our MSSQL Migration with SSMS article.

1. Open SSMS (Microsoft SQL Server Management Studio) on the source server, log in to the SQL instance and open a New Query window. Run the following query:

SELECT name FROM master.sys.databases

This command will output a list of all MSSQL databases on your server. To copy this list out, click anywhere in the results and use the keyboard shortcut CTRL+A (Command + A for Mac users) to select all databases. After highlighting all the databases right click and select copy.

2. Open Notepad, paste in your results and delete all databases (in the newly copied notepad text) you do NOT wish to migrate, as well as deleting the following entries:

  • master
  • tempdb
  • model
  • msdb

These entries are the system’s databases, and copying them is not necessary. Make sure to delete everything except explicitly the databases you need to migrate.  You should now have a list of all required databases separated by a line. i.e.

  • AdventureWorks2012
  • AdventureWorks2014
  • AdventureWorks2016

3. Save this result on the computer as C:\databases.txt.

4. Create a new Notepad window, copy/paste the following into the document and save it as C:\db-backup.bat

mkdir %systemdrive%\dbbackups
for /F "tokens=*" %%a in (databases.txt) do ( sqlcmd.exe -Slocalhost -Q"BACKUP DATABASE %%a TO DISK ='%systemdrive%\dbbackups\%%a.bak' WITH STATS" )

5. Now that you’ve saved the file as C:\db-backup.bat, navigate to the Start menu and type cmd and right click on Command Prompt to select Run as Administrator.Type the following command:

cd C:\

And hit enter. Afterward, type db-backup.bat and hit enter once again.

At this point, your databases have begun exporting and you will see the percentage progress of each databases export (pictured below).

Command line shows the process of each database that is exported.

Take note of any failed databases, as you can re-run the batch file when it’s done, using only the databases that may have failed. If the databases are failing to back up, take note of the error message displayed in the command prompt, address the error by modifying the existing C:\databases.txt file to include only the failed databases and re-run db-backup.bat until all databases are successfully exported.

 

By now you have the folder C:\dbbackups\ that contains .bak files for each database you want to migrate. You will need to copy the folder and your C:\databases.txt file to the destination server. There are numerous ways to move your data to the destination server; you can use USB, Robocopy or FTP. The folder on the C drive of the destination server should be called C:\dbbackups . It’s important to accurately name the file as our script will be looking for the .bak files here. Be sure that the destination server has your C:\databases.txt file as well, as our script will be looking for the database names here.

 

1. Open a Notepad and copy/paste the following into the document and save it as C:\db-restore.bat

for /F "tokens=*" %%a in (C:\databases.txt) do (
sqlcmd.exe -E -Slocalhost -Q"RESTORE DATABASE %%a FROM DISK='%systemdrive%\dbbackups\%%a.bak' WITH RECOVERY"
)

2. Save the file as C:\db-restore.bat 

3. Navigate to the Start menu and type cmd.

4. Right click on Command Prompt and select Run as Administrator. Type the following command:

cd C:\

and hit Enter. Now type db-restore.bat and hit Enter.

Your databases have now begun importing. You will see the percentage of each databases restoration and the message “RESTORE DATABASE successfully processed” for each database that has been successfully processed.

Take note of any failed databases, as you can re-run the batch file when it’s done, using only the databases that have failed. If the databases are failing to back up, take note of the error message displayed in the command prompt, address the error (you can change the batch file as necessary), modify C:\databases.txt to include only the failed databases and re-run db-restore.bat until all databases are successfully exported.

Congratulations, you have now backed up and restored all of your databases to the new server. If you have any login issues while testing the SQL connections on the destination server, refer to the Migrating Microsoft SQL Logins (anchor link) section of this article and follow the steps therein. To migrate views or stored procedures please refer to the Migrating Views and Stored Procedures section. Every SQL server will have it’s own configurations and obstacles to face but we hope this article has given you a strong foundation for your Microsoft SQL Server Migration.

 

SQL Database Migration with SSMS

Migrating MSSQL between servers can be challenging without the proper guidelines to keep you on track. In this article, I will be outlining the various ways to migrate Microsoft SQL Server databases between servers or instances. Whether you need to move a single database,  many databases, logins or stored procedures and views we have you covered!

There are many circumstances where you will need to move a database or restore databases. The most common reasons are:

 

  • Moving to an entirely new server.
  • Moving to a different instance of SQL.
  • Creating a development server or going live to a production server.
  • Restoring databases from a backup.

 

There are two main ways to move SQL databases. Manually with Microsoft SQL Server Management Studio (SSMS) or with the command line. The method you choose depends on what you need to accomplish. If you are moving a single database or just a few, manually backing up and restoring the databases with SSMS will be the easiest approach. If you are moving a lot of databases (think more than 10) then using the command line method will speed up the process. The command line method takes more prep work beforehand, but if you are transferring dozens of databases, then it is well worth the time spent configuring the script instead of migrating each database individually. If you aren’t sure which method to use, try the manual approach first while you get comfortable with the process. I recommend reading all the way through for a deeper understanding of the methodology.

 

Useful References for Terminology

SSMS – An acronym for Microsoft SQL Server Management Studio.

Source Server – The server or instance you are moving databases from or off.

Destination Server – The server or instance you are moving databases to.

 

Moving SQL databases with the manual method can be very easy. It is the preferred process for transferring a few or smaller databases. To follow this part of the guide, you must have MSSQL, and Microsoft SQL Server Management Studio (SSMS) installed.

 

1. Begin by logging into the Source server (the server you are moving databases from or off of). You will want to open Microsoft SQL Server Management Studio by selecting Start > Microsoft SQL Server >  Microsoft SQL Server Management Studio.

2.Log into the SQL server using Windows Authentication or SQL Authentication.

3. Expand the server(in our case SQL01), expand Databases, select the first database you want to move (pictured below).

Select your database within Microsoft SQL Server Management Studio.

4. Right click on your database and select Tasks then click Back Up.

Back up button in Microsoft SQL Server Management Studio.

5. From here you are now at the Back Up Database screen. You can choose a Backup Type such as Full or Differential, make sure the correct database is selected, and set the destination for the SQL backup. For our example, we can leave the Backup Type as Full.

6. Under Backup Type, check the box for “Copy-only backup.” If you are running DPM or another form of server backup, backing up without the Copy-Only flag will cause a break in the backup log chain.

7. You will see a location under Destination for the path of the new backup. Typically you will Remove this entry then Add a new one to select a folder that SQL has read/write access. Adding a new Backup Destination shows a path similar to the following:

C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\

This C:\ path is where your stored database backup is. Note this location for later reference, as this is the default path to stored backups and will have to have proper read/write access for SQL services.

Note:
Advanced users may be comfortable leaving the destination as is, provided the permissions are correct on the output folder.

8. Next, append a filename to the end of this path such as AdventureWorks2012-081418.bak – Be sure to end the filename with the extension .bak and select OKSet the file name with the .bak extension in Microsoft SQL Server Management Studio

10. Once you have pressed OK on the Select Backup Destination prompt, you are ready to back up the database! All you need to do now is hit OK, and the database will begin backing up. You will see a progress bar in the bottom left-hand corner, and when the backup is complete, a window will appear saying ‘The backup of database ‘AdventureWorks2012’ completed successfully.

Navigate to the destination path, noted earlier, (in this case C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\) you will see your newly created file (in this case AdventureWorks2012-081418.bak) – Congratulations! This file is the full export of your database and is ready to be imported to the new server.  If you have more databases, then repeat the steps above for each database you are moving. After copying all database process to the next step of restoring databases to the destination server.

 

You should now have a .bak file of all your databases on the source server. These database files need to be transferred to the destination server. There are numerous ways to move your data to the destination server; you can use USB, Robocopy or FTP. After copying a database you can store it on your destination server,  for our example, we have stored it on the C drive in a folder named C:\dbbackups .

1. Open Microsoft SQL Server Management Studio.

2. Log in to the SQL server using Windows Authentication or SQL Authentication.

3. Expand the server and right click on Databases and select Restore Database.

4. The Restore Database screen looks very similar to the Back Up Database screen.Under Source, you will want to select Device instead of Database. Selecting Device allows you to restore directly from a file. Once you’ve chosen Device, click the browse icon […]

5. Select Add, then navigate to the folder in which your .bak files lives. (In this case, C:\dbbackups).

6. Select the first database .bak you would like to restore and click OK.

Select the .bak file to import your database into the destination server via SSMS.

7. Click OK and now you are ready to import the database. Before importing, let’s take a look at the Options section on the left-hand side. Under Options, you will see other configurations for restoring databases such as Overwrite the Existing Database, Preserve the Replication Settings and Restrict Access to the Restored DatabaseIn this case, we are not replacing an existing database so I will leave all these options unchecked. If you wanted to replace an existing database (for example, the backed up database has newer data than on the destination server or you are replacing a development or production database) then simply select Overwrite the Existing Database.

Note:
Advanced users may be comfortable leaving the destination as is, provided the permissions are correct on the output folder.

8. Clicking OK  begins the restore process as indicated by the popup window that reads ‘Database ‘AdventureWorks2012′ restored successfully.’ You have migrated your database from the source to the destination server.

Repeat this process for each database that you are migrating. You can then update path references in your scripts/application to point to the new server, verify that the migration was successful.

 

After importing your databases if you are unable to connect using your SQL login, you may receive the error ‘Login failed for user ‘example.’ (Microsoft SQL Server, Error: 18456).‘ Because the database is in the Traditional Login and User Model, logins are stored separately in the source server and credentials are not contained within the database itself. From this point on, the destination server can be configured to use the Contained Database User Model which keeps the logins in your database and out of the source server. (You can read more about this here.)Until then, we will have to move and interact with the users as part of the Traditional model. Continue below to proceed with the migration of your SQL users.

Backing up and restoring the databases did move your SQL logins relation to the databases (your logins are still associated with the correct databases with the correct permissions) but the actual logins itself did not transfer to the new server.  You can verify this by opening SSMS on the destination server and navigating to Server > Security > Logins. You will notice that any custom SQL logins you created on the previous server did not transfer over here, but if you go to Server > Databases > Your Database (AdventureWorks2012 in this case) > Security > Users you’ll see the correct login associated with the database.

If you have one or two SQL users, you can just delete the user’s association to the database in Servers > Databases > AdventureWorks2012 > Security > Users, re-create the user in Server > Security > Logins and map it to the proper database.

If you have a lot of logins, you will have to follow an additional process outlined below. To migrate all SQL users, open a New Query window on the source server and run the following script:

SQL Login Script
USE master
GO
IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
DROP PROCEDURE sp_hexadecimal
GO
CREATE PROCEDURE sp_hexadecimal
@binvalue varbinary(256),
@hexvalue varchar (514) OUTPUT
AS
DECLARE @charvalue varchar (514)
DECLARE @i int
DECLARE @length int
DECLARE @hexstring char(16)
SELECT @charvalue = '0x'
SELECT @i = 1
SELECT @length = DATALENGTH (@binvalue)
SELECT @hexstring = '0123456789ABCDEF'
WHILE (@i <= @length)
BEGIN
DECLARE @tempint int
DECLARE @firstint int
DECLARE @secondint int
SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))
SELECT @firstint = FLOOR(@tempint/16)
SELECT @secondint = @tempint - (@firstint*16)
SELECT @charvalue = @charvalue +
SUBSTRING(@hexstring, @firstint+1, 1) +
SUBSTRING(@hexstring, @secondint+1, 1)
SELECT @i = @i + 1
END
SELECT @hexvalue = @charvalue
GO
IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
DROP PROCEDURE sp_help_revlogin
GO
CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS
DECLARE @name sysname
DECLARE @type varchar (1)
DECLARE @hasaccess int
DECLARE @denylogin int
DECLARE @is_disabled int
DECLARE @PWD_varbinary varbinary (256)
DECLARE @PWD_string varchar (514)
DECLARE @SID_varbinary varbinary (85)
DECLARE @SID_string varchar (514)
DECLARE @tmpstr varchar (1024)
DECLARE @is_policy_checked varchar (3)
DECLARE @is_expiration_checked varchar (3)
DECLARE @defaultdb sysname
IF (@login_name IS NULL)
DECLARE login_curs CURSOR FOR
SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
sys.server_principals p LEFT JOIN sys.syslogins l
ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name <> 'sa'
ELSE
DECLARE login_curs CURSOR FOR
SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
sys.server_principals p LEFT JOIN sys.syslogins l
ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name = @login_name
OPEN login_curs
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
IF (@@fetch_status = -1)
BEGIN
PRINT 'No login(s) found.'
CLOSE login_curs
DEALLOCATE login_curs
RETURN -1
END
SET @tmpstr = '/* sp_help_revlogin script '
PRINT @tmpstr
SET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'
PRINT @tmpstr
PRINT ''
WHILE (@@fetch_status <> -1)
BEGIN
IF (@@fetch_status <> -2)
BEGIN
PRINT ''
SET @tmpstr = '-- Login: ' + @name
PRINT @tmpstr
IF (@type IN ( 'G', 'U'))
BEGIN -- NT authenticated account/group
SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH DEFAULT_DATABASE = [' + @defaultdb + ']'
END
ELSE BEGIN -- SQL Server authentication
-- obtain password and sid
SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )
EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT
EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
-- obtain password policy state
SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD = ' + @PWD_string + ' HASHED, SID = ' + @SID_string + ', DEFAULT_DATABASE = [' + @defaultdb + ']'
IF ( @is_policy_checked IS NOT NULL )
BEGIN
SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked
END
IF ( @is_expiration_checked IS NOT NULL )
BEGIN
SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' + @is_expiration_checked
END
END
IF (@denylogin = 1)
BEGIN -- login is denied access
SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )
END
ELSE IF (@hasaccess = 0)
BEGIN -- login exists but does not have access
SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )
END
IF (@is_disabled = 1)
BEGIN -- login is disabled
SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'
END
PRINT @tmpstr
END
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
END
CLOSE login_curs
DEALLOCATE login_curs
RETURN 0
GO

This script creates two stored procedures in the source database which helps with migrating these logins. Open a New Query window and run the following:
EXEC sp_help_revlogin

This query outputs a script that creates new logins for the destination server. Copy the output of this query and save it for later. You will need to run this on the destination server.

Once you’ve copied the output of this query, login to SSMS on the destination server and open a New Query window. Paste the contents from the previous script (it should have a series of lines that look similar to — Login: BUILTIN\Administrators
CREATE LOGIN [BUILTIN\Administrators] FROM WINDOWS WITH DEFAULT_DATABASE = [master]) and hit Execute.

You have now successfully imported all SQL logins and can now verify that the databases have been migrated to the destination server by using your previous credentials.

Views and stored procedures will migrate with the database if you are using the typical SQL Tape backups. Follow the instructions below if you need to migrate views and stored procedures independently.

  1. Open Microsoft SQL Management Studio on the Source server.
  2. Log in to your SQL server.
  3. Expand the server and as well as Databases.
  4. Right click on the name of your database and go to Tasks > Generate Scripts.
  5. Click Next.
  6. We will change Script entire database and all database objects to Select specific database objects and only check Views and Stored Procedures.Transfer Stored Procedures and Views within Microsoft SQL Server Management Studio
  7. Click Next, notice the Save to File option. Take note of the file path listed. In my case, it is C:\Users\Administrator\Documents\script.sql – The path of saved views and stored procedures.
  8. Click Next >> Next >>Finish, and select C:\Users\Administrator\Documents\script.sql and copy it to the destination server.
  9. Go to the destination server, open SSMS and log in to the SQL server.
  10. Go to File > Open > File or use the keyboard shortcut CTRL+O to open the SQL script. Select the file C:\Users\Administrator\Documents\script.sql to open it.
  11. You will see the script generated from the source server containing all views and stored procedures. Click Execute or use the keyboard shortcut F5 and run the script.
Note:
Unfortunately, there is no built-in way to do this with the command line. There are 3rd party tools and even a tool by Microsoft called mssql-scripter for more advanced scripting.

You have now migrated the views and stored procedures to your destination server! Repeat this process for each database you are migrating. A little guidance goes a long way in database administration. Every SQL server will have it’s own configurations and obstacles to face but we hope this article has given you a strong foundation for your Microsoft SQL Server Migration.

Looking for a High Availability, platform-independent SQL service that is easily scalable and can grow with your business? Check out our SQL as a Service product offered at Liquid Web. Speak with one of our amazing Hosting Advisers to find the perfect solution for you!

 

Migration to Managed WooCommerce

Liquid Web is here to support your migration needs into our Managed WooCommerce Hosting platform. Whether you are migrating from an external or internal source, our in-house team of migration experts transforms the data migration process into a simple task. To ensure the smoothest and best possible data transfer, we have a quick overview and a few points for your consideration.

 

Our first step includes taking a copy of your live site (known as the origin site) and migrating it over to our Managed WooCommerce Hosting platform. Rest assured, when performing the migration, the only changes made to the site will be to assist in the movement. Within this timeframe, it is advised to avoid making changes or updates to the site as it will extend the migration timeline and could result in data loss. Changes and updates are included but not limited to themes, designs, contents, products, blog posts or WordPress versions. The initial sync process should result in no downtime for your live site.

Once the initial sync is complete, our Migration Specialists perform a series of basic tests to the site. During this time, our team will send information on ways to test out your new site to ensure that all aspects have carried over correctly and are in working order. Before going live, it is essential to take the time to thoroughly review your site and if at any point you do find a discrepancy our specialist is there to assist.

The third and most exciting step is the push to go live. We will coordinate the best date and time for the final sync of your site. This last sync will ensure the latest data on orders, products, and customers transfers to your new server. Upon completion of the final sync, you will be asked to update the staging domain’s name and DNS record. With a little DNS propagation time, you will begin to see the new site populate!

With the updating of DNS and the site name, you are now entirely done with the migration process. In subsequent steps, we will create a ticket with our Product Team to connect your store to our partnered applications, Glew and Jilt. Credentials to these valued applications will be sent out in an email, after which, our product team can suggest performance optimization methods to get the most out of your eCommerce store.

 

Knowing the details behind the migration process aligns us with our next step in creating a migration request from your Liquid Web control panel! Once completed, our Migration Specialists will be in touch to schedule the migration and answer any questions you may have.

 

The 8 Step Checklist to a better migration

8 Tips to a Smooth Migration

A recent Liquid Web survey revealed that businesses are often held back from choosing a better hosting partner by the “what-if” situation when a migration presents. Nearly a quarter of consumers who decide not to switch to a new provider cited fear of the migration as the biggest reason for maintaining the status quo. Even if they believe that the new hosting provider would be better. Continue reading “The 8 Step Checklist to a better migration”

What to expect for a Windows Server Migration?

If you ever need to upgrade the hardware on your Windows server, Liquid Web’s Windows team is happy to help you through the migration process. While it is not the most simple process, keeping in communication with our Heroic Support teams will help make things go smoothly. Before beginning a Windows server migration it’s a good idea to familiarize yourself with the overall process so you know what to expect.

Things to Consider

There are a few things to keep in mind when starting a migration. Review the items listed here to make sure you’re prepared for the process. Continue reading “What to expect for a Windows Server Migration?”

What to Expect During a Site Migration

The Migration Team at Liquid Web is dedicated to providing customers with an efficient and as uneventful a migration as possible. It is important that we work together to ensure an effective transfer of information. No matter if you are migrating from a current Liquid Web server, or from another host, we make it as simple as possible.
Continue reading “What to Expect During a Site Migration”