<p>Set up a local development environment, and invest in a workflow as described here: <a href="https://nystudio107.com/blog/database-asset-syncing-between-environments-in-craft-cms" rel="noreferrer">Database &amp; Asset Syncing Between Environments in Craft CMS</a></p>

CC BY-SA 3.0
2017-11-15T22:39:42.430Z
This answer should be marked correct.
CreateSean
CC BY-SA 3.0
2017-11-09T08:08:34.830Z
2017-11-09T08:08:34.830Z
andrew.welch
<p>As a more detailed answer than in my comments.</p>
<p>You should never make such huge changes in a running live system without deactivating it. No matter how experienced you are with twig, craft, php... you can easily make mistakes and you do not want users/customers to see them because they may not return to your page. There are many reasons why it is necessary to create a development environment for these kind of things.</p>
<ol>
<li>Debugging/Error messages you do not want to activate the dev mode for twig because users would see errors if there are any. But as a developer you have to see your exceptions/syntax errors.</li>
<li>Matrix fields in craft: in some projects users can have an incredible amount of different combinations to create pages with many different matrix block types and it requires much time to test them all. I had pages with over 100 different different possibilities to order/render the content because our customer wanted it that way. So you need to create many different entries/edit them and so on. You do not want to do that live</li>
</ol>
<p><strong>TL/DR</strong><br>
The best solution would be creating a development environment for your page</p>
<ol>
<li><p>Go to your preferred SQL interface (usually phpMyAdmin) and export your entire database</p>
</li>
<li><p>Import that sql file into another database (you can use your localhost with xampp too if you are the only designer)</p>
</li>
<li><p>copy your entire project to your new environment - either on a new server or at localhost</p>
</li>
<li><p>change the design</p>
</li>
<li><p>upload all your changes (usually the <code>templates</code> folder, as well as all assets - js, css, image files)</p>
<p>You don't have to worry about the license for craft <a href="https://craftcms.com/support/license-enforcement" rel="noreferrer">click</a> as long as you follow these rules you won't get in trouble for having the same project on different servers/locations.</p>
</li>
</ol>

CC BY-SA 3.0
2017-11-09T06:40:14.173Z
2017-11-09T06:40:14.173Z
2020-06-17T08:56:27.903Z
Robin Schambach
<p>To migrate an existing site you'll want to create a second environment to work in:</p>

<ul>
<li>www.yourwebsite.com (your live site)</li>
<li>new.yourwebsite.com (your new website)</li>
</ul>

<p>Some of the other answers discuss setting up a second environment, so I'll leave that topic to them. For a large site, you have the good approach to not change many things. When your changing systems, when possible, it's often good to migrate things in a 1-to-1 manner. This helps keep things simpler with the migration and have more focus on the many other parts of the migration where you may run into complexity.</p>

<p>From your question, it sounds like the migration is driven by a redesign. While the design is an important part of the transition, there will also be several other phases of your migration and it's important to consider all of them to keep the site running smoothly and expectations aligned with an appropriate schedule.</p>

<p>Consider the following phases of the migration</p>

<ul>
<li><strong>Planning</strong> - Determine who's responsible for what.  </li>
<li><strong>Content Architecture</strong> - Build out the content model for the new site in Craft and create a mapping between all the sections and fields of the old site and new site.</li>
<li><strong>Template Migration</strong> - Migrate the HTML, CSS, JS to the new site</li>
<li><strong>Asset Migration</strong> - All of your assets will need to get into the new system. Even if you have your assets on a cloud service they will need to get synced with the new system and this can take time with large amounts of files. If your existing site manages assets in Rich Text fields or other messy-HTML type ways, consider what it will take to migrate those into your new data structure.</li>
<li><strong>SEO Migration</strong> - As you build out your content architecture and prepare for migration, you'll want to make sure you are taking SEO into account as you transition things over. Run a scan of your site before and after the transition to make sure you know if anything major changes. Make sure to setup 301 redirects and monitor your traffic for a reasonable period of time after the transition to confirm things are working as expected and tweak things.</li>
<li><strong>Data Migration</strong> - Migrating the data often takes several iterations to get right. If you have highly relational content, it may matter what order you migrate things in. You'll also need to coordinate this phase with the people adding content.</li>
<li><strong>Deployment</strong> - You can put a freeze on the main website and migrate and launch the new site. Or you can run a migration with most of the data and have people enter data into both systems for a week to confirm that things are working as needed with the new site. Either way, there will likely be some timing issues to sort out about the live site and the final data migration and the transition. It's much easier to plan to deploy the new site to a new server than to try to overwrite the existing site in the location where it is. Make sure you're considering SEO at this point and that you have a plan in place on how you are handling the transition and monitoring of your existing search standing.</li>
</ul>

<p>In my experience with large migrations, there is <em>ALWAYS</em> something unexpected that presents a challenge. Don't expect to have an accurate estimate at the planning stage. Make sure people on your team understand that the estimate will be refined and get more accurate as you go through the phases of the migration.</p>

<p>If you are not familiar with parts of the migration process, consider hiring someone to help make sure parts of it go smoothly. It's better to spend the time up front getting things right or have a specialist help with a particular part you are less familiar with than accidentally lose all of your existing search listings.</p>

CC BY-SA 3.0
2017-11-13T13:47:11.360Z
2017-11-13T13:47:11.360Z
Ben Parizek
<p>I have no experience using Craft but will be redesigning a large site using Craft. Most of the content will not be moved or restructured, I'll mostly be making cosmetic changes with HTML and CSS.</p>

<p>What is the best way to redesign a site while it is already live? I'd like to keep the CMS active whilst I'm making changes so that other people on my team can keep adding content before activating certain pages.</p>

CC BY-SA 3.0
2017-11-08T20:08:11.140Z
You should never make such changes in a running live system without deactivating it. We always have copies of the projects on development servers and make our changes there. As soon as we finished our work (and more importantly fixed all bugs) we upload it to the live server. So you should either deactivate the page temporarily or change the templates on a test system. With a development server you'll be able to make your changes while others can add content to the live system
Robin Schambach
CC BY-SA 3.0
2017-11-08T20:25:08.047Z
Thanks @RobinSchambach. So do you duplicate the site and then swap out the /template folder when it's finished?
univers_
CC BY-SA 3.0
2017-11-08T20:36:44.963Z
That's exactly how it works. Go to your preferred SQL interface (usually phpMyAdmin) select the database you use and export it. Then you'll create a new database on your test system - you can even work on localhost with xampp - import the database, copy all files as well and start your work. When you think you are ready just upload your entire css/js and template folders and you are done. This way others can continue to manage the content while you can create new entries to test every scenario - matrix combinations and such -
Robin Schambach
CC BY-SA 3.0
2017-11-08T21:33:25.293Z
Those comments would make a solid answer @RobinSchambach. ;)
Brad Bell
<templating><css>
Best way to handle redesign of large site
# Best way to handle redesign of large site

(Asked by: username_0 on 2017-11-08)

I have no experience using Craft but will be redesigning a large site using Craft. Most of the content will not be moved or restructured, I'll mostly be making cosmetic changes with HTML and CSS.

What is the best way to redesign a site while it is already live? I'd like to keep the CMS active whilst I'm making changes so that other people on my team can keep adding content before activating certain pages.

**Tags:** templating, css

> **Comments:**
> **username_1**: You should never make such changes in a running live system without deactivating it. We always have copies of the projects on development servers and make our changes there. As soon as we finished our work (and more importantly fixed all bugs) we upload it to the live server. So you should either deactivate the page temporarily or change the templates on a test system. With a development server you'll be able to make your changes while others can add content to the live system  
> **username_0**: Thanks @RobinSchambach. So do you duplicate the site and then swap out the /template folder when it's finished?  
> **username_1**: That's exactly how it works. Go to your preferred SQL interface (usually phpMyAdmin) select the database you use and export it. Then you'll create a new database on your test system - you can even work on localhost with xampp - import the database, copy all files as well and start your work. When you think you are ready just upload your entire css/js and template folders and you are done. This way others can continue to manage the content while you can create new entries to test every scenario - matrix combinations and such -  
> **username_2**: Those comments would make a solid answer @RobinSchambach. ;)  

---

## 3 answers

### Answer by username_3 on 2017-11-09. Score: 7

Set up a local development environment, and invest in a workflow as described here: [Database & Asset Syncing Between Environments in Craft CMS](https://nystudio107.com/blog/database-asset-syncing-between-environments-in-craft-cms)

> **Comments:**
> **username_4**: This answer should be marked correct.  

---

### Answer by username_1 on 2017-11-09. Score: 6

As a more detailed answer than in my comments.

You should never make such huge changes in a running live system without deactivating it. No matter how experienced you are with twig, craft, php... you can easily make mistakes and you do not want users/customers to see them because they may not return to your page. There are many reasons why it is necessary to create a development environment for these kind of things.

1. Debugging/Error messages you do not want to activate the dev mode for twig because users would see errors if there are any. But as a developer you have to see your exceptions/syntax errors.
2. Matrix fields in craft: in some projects users can have an incredible amount of different combinations to create pages with many different matrix block types and it requires much time to test them all. I had pages with over 100 different different possibilities to order/render the content because our customer wanted it that way. So you need to create many different entries/edit them and so on. You do not want to do that live

**TL/DR**  
The best solution would be creating a development environment for your page

1. Go to your preferred SQL interface (usually phpMyAdmin) and export your entire database
2. Import that sql file into another database (you can use your localhost with xampp too if you are the only designer)
3. copy your entire project to your new environment - either on a new server or at localhost
4. change the design
5. upload all your changes (usually the `templates` folder, as well as all assets - js, css, image files)

   You don't have to worry about the license for craft [click](https://craftcms.com/support/license-enforcement) as long as you follow these rules you won't get in trouble for having the same project on different servers/locations.


---

### Answer by username_5 on 2017-11-13. Score: 2

To migrate an existing site you'll want to create a second environment to work in:

* www.yourwebsite.com (your live site)
* new.yourwebsite.com (your new website)

Some of the other answers discuss setting up a second environment, so I'll leave that topic to them. For a large site, you have the good approach to not change many things. When your changing systems, when possible, it's often good to migrate things in a 1-to-1 manner. This helps keep things simpler with the migration and have more focus on the many other parts of the migration where you may run into complexity.

From your question, it sounds like the migration is driven by a redesign. While the design is an important part of the transition, there will also be several other phases of your migration and it's important to consider all of them to keep the site running smoothly and expectations aligned with an appropriate schedule.

Consider the following phases of the migration

* **Planning** - Determine who's responsible for what.
* **Content Architecture** - Build out the content model for the new site in Craft and create a mapping between all the sections and fields of the old site and new site.
* **Template Migration** - Migrate the HTML, CSS, JS to the new site
* **Asset Migration** - All of your assets will need to get into the new system. Even if you have your assets on a cloud service they will need to get synced with the new system and this can take time with large amounts of files. If your existing site manages assets in Rich Text fields or other messy-HTML type ways, consider what it will take to migrate those into your new data structure.
* **SEO Migration** - As you build out your content architecture and prepare for migration, you'll want to make sure you are taking SEO into account as you transition things over. Run a scan of your site before and after the transition to make sure you know if anything major changes. Make sure to setup 301 redirects and monitor your traffic for a reasonable period of time after the transition to confirm things are working as expected and tweak things.
* **Data Migration** - Migrating the data often takes several iterations to get right. If you have highly relational content, it may matter what order you migrate things in. You'll also need to coordinate this phase with the people adding content.
* **Deployment** - You can put a freeze on the main website and migrate and launch the new site. Or you can run a migration with most of the data and have people enter data into both systems for a week to confirm that things are working as needed with the new site. Either way, there will likely be some timing issues to sort out about the live site and the final data migration and the transition. It's much easier to plan to deploy the new site to a new server than to try to overwrite the existing site in the location where it is. Make sure you're considering SEO at this point and that you have a plan in place on how you are handling the transition and monitoring of your existing search standing.

In my experience with large migrations, there is *ALWAYS* something unexpected that presents a challenge. Don't expect to have an accurate estimate at the planning stage. Make sure people on your team understand that the estimate will be refined and get more accurate as you go through the phases of the migration.

If you are not familiar with parts of the migration process, consider hiring someone to help make sure parts of it go smoothly. It's better to spend the time up front getting things right or have a specialist help with a particular part you are less familiar with than accidentally lose all of your existing search listings.


---

