<p>Here's a blog I wrote that might be useful to you: <a href="https://nystudio107.com/blog/database-asset-syncing-between-environments-in-craft-cms" rel="nofollow noreferrer">Database &amp; Asset Syncing Between Environments in Craft CMS</a></p>
<p>This was written before <a href="https://craftcms.com/docs/3.x/project-config.html" rel="nofollow noreferrer">Project Config</a> was a thing, but the technique works great with Project Config too.</p>

CC BY-SA 4.0
2021-04-23T18:20:35.657Z
Andrew, amazing. Thank you so much. I'll be studying your post.
mauricio
CC BY-SA 4.0
2021-04-23T21:25:05.940Z
Andrew, thank you so much for sharing your blog post. It's very helpful and just what I needed. In general terms we use the same process in the CMS we are migrating from.   I think I'll be using your dB script. I have only 1 extra questions:
1. Does it work in a local environment setup using Nitro?
2. You mentioned that you wrote the article before Project Config was a thing. Since we are so new to CraftCMS, we don't know what that fully means yet ;), Is there anything we should be aware of when using the script?
thanks a million!
mauricio
CC BY-SA 4.0
2021-04-23T23:52:14.907Z
I'm not sure how you'd use the scripts with Nitro -- but here's the Docker setup I use that includes a script that pulls the db down into a Docker container: [An Annotated Docker Config for Frontend Web Development](https://nystudio107.com/blog/an-annotated-docker-config-for-frontend-web-development)
andrew.welch
CC BY-SA 4.0
2021-04-23T17:23:38.857Z
2021-04-23T17:23:38.857Z
andrew.welch
<blockquote>
<p>However, during the dB export, we need to update all the entries to reflect the local URLs. How does this work with Craft? do dB entries need to be updated to reflect the new URLs?</p>
</blockquote>
<p>Sounds like you might be coming from something like WP where it hardcodes URL and links in the database? You'll be happy to know that is not the case in Craft.</p>
<p>Craft generally uses <a href="https://craftcms.com/docs/3.x/reference-tags.html" rel="nofollow noreferrer">Reference tags</a> when it needs to  store links to  assets, entries, etc. in the database. This neatly sidesteps around the problem of having to do a find/replace every time you move environments since those URLs are &quot;built up&quot; on-the-fly.</p>
<p>However, this only works for new content the you create in the CMS. On the off-chance that you're moving legacy content from another CMS to Craft, you can use Craft's built-in find/replace tool inside Utilities to do the find/replace.</p>
<blockquote>
<p>Is there no other way to have a single large migration (contents, settings, fields, etc.) happening at once?</p>
</blockquote>
<p>Generally you want your migration to go one-way.</p>
<p>You'll want to read up on <a href="https://craftcms.com/docs/3.x/project-config.html" rel="nofollow noreferrer">Project Config</a> but in general, you start on local then push your project config to staging or production. This prompts Craft to update the structural items in the CMS (added sections, fields, etc.)</p>
<p>Moving actual content from staging to production itself is more of a challenge. The Migration Assistant you linked up does lets you export content as well as structure, but usually you want to keep those sorts of changes as narrowly defined as possible.</p>
<p>Databases are highly structured beasts. When you start adding content on production then try to push an update from staging, that's a recipe for all sorts of breakage.</p>
<p>As an example, say you have an entry on staging that relates to a bunch of different categories, assets, and entries. Unless those entries, categories, and assets are already created on production, how does Craft know what to do with all of it?</p>
<p>On a technical level, primary and foreign keys could be different, for example.  Some systems get around this with GUIDs, but in general, it's still a hard problem to solve unless the two are kept in sync somehow—which is what enterprise systems generally do.</p>
<p>WP for example has more tools to deal with this sort of thing but they're still more simplistic in this sense because it doesn't have all the relational capabilities of Craft.</p>

CC BY-SA 4.0
2021-04-27T22:56:20.900Z
Hi RitterKnight. Thanks a lot for your thorough answer. Yes, you are right, I'm coming from WP(!), so in mind, there's always the step of exporting, and replacing data, the dB tables. It's great to hear that Craft completely avoids this problem.

I'll have to study the documentation well and do several tests to get an efficient and safe deployment method.
mauricio
CC BY-SA 4.0
2021-04-27T23:12:19.880Z
In the end, the plan is to get content from the Staging dB into our local machines; Media -images, videos, etc.- will remain in the Staging server; And we will commit and push to the remotes templates and other important files we change during dev. 

Thank you for all the help and we will be probably knocking at the door soon with more questions.
mauricio
CC BY-SA 4.0
2021-04-25T19:15:23.620Z
2021-04-25T19:15:23.620Z
RitterKnight
<p>I'm new to CraftCMS and have a few basic questions about synching contents between local and remote development environments. This has been discussed in other posts by I'm looking for more specific answers.</p>
<ol>
<li><p>Traditionally, in the old CMS we use, we do all content changes in the remote dB. And then each team member imports the remote dB and updates their local dB (similar to what is described <a href="https://craftcms.stackexchange.com/questions/10/whats-the-best-practice-for-handling-data-migration-and-organization-across-dev">here</a>). However,  during the dB export, we need to update all the entries to reflect the local URLs. How does this work with Craft? do dB entries need to be updated to reflect the new URLs? And is there a widely used plugin for this step?</p>
</li>
<li><p>Reviewing a Craft <a href="https://github.com/dgrigg/craft-migration-assistant" rel="nofollow noreferrer">migration plugin</a>, it mentions that one has to follow a migration dependency order, and that one has to break migrations into smaller steps to prevent issues, instead of one large migration. Is this the general practice for Craft? Is there no other way to have a single large migration (contents, settings, fields, etc.) happening at once?</p>
</li>
</ol>
<p>Thank you so much.</p>

<database><migration><deployment><environments>
Synching content and template files across environments
# Synching content and template files across environments

(Asked by: username_0 on 2021-04-23)

I'm new to CraftCMS and have a few basic questions about synching contents between local and remote development environments. This has been discussed in other posts by I'm looking for more specific answers.

1. Traditionally, in the old CMS we use, we do all content changes in the remote dB. And then each team member imports the remote dB and updates their local dB (similar to what is described [here](https://craftcms.stackexchange.com/questions/10/whats-the-best-practice-for-handling-data-migration-and-organization-across-dev)). However, during the dB export, we need to update all the entries to reflect the local URLs. How does this work with Craft? do dB entries need to be updated to reflect the new URLs? And is there a widely used plugin for this step?
2. Reviewing a Craft [migration plugin](https://github.com/dgrigg/craft-migration-assistant), it mentions that one has to follow a migration dependency order, and that one has to break migrations into smaller steps to prevent issues, instead of one large migration. Is this the general practice for Craft? Is there no other way to have a single large migration (contents, settings, fields, etc.) happening at once?

Thank you so much.

**Tags:** database, migration, deployment, environments

---

## 2 answers

### Answer by username_1 on 2021-04-23. Score: 1

Here's a blog I wrote that might be useful to you: [Database & Asset Syncing Between Environments in Craft CMS](https://nystudio107.com/blog/database-asset-syncing-between-environments-in-craft-cms)

This was written before [Project Config](https://craftcms.com/docs/3.x/project-config.html) was a thing, but the technique works great with Project Config too.

> **Comments:**
> **username_0**: Andrew, amazing. Thank you so much. I'll be studying your post.  
> **username_0**: Andrew, thank you so much for sharing your blog post. It's very helpful and just what I needed. In general terms we use the same process in the CMS we are migrating from.   I think I'll be using your dB script. I have only 1 extra questions: 1. Does it work in a local environment setup using Nitro? 2. You mentioned that you wrote the article before Project Config was a thing. Since we are so new to CraftCMS, we don't know what that fully means yet ;), Is there anything we should be aware of when using the script? thanks a million!  
> **username_1**: I'm not sure how you'd use the scripts with Nitro -- but here's the Docker setup I use that includes a script that pulls the db down into a Docker container: [An Annotated Docker Config for Frontend Web Development](https://nystudio107.com/blog/an-annotated-docker-config-for-frontend-web-development)  

---

### Answer by username_2 on 2021-04-25. Score: 1

> However, during the dB export, we need to update all the entries to reflect the local URLs. How does this work with Craft? do dB entries need to be updated to reflect the new URLs?

Sounds like you might be coming from something like WP where it hardcodes URL and links in the database? You'll be happy to know that is not the case in Craft.

Craft generally uses [Reference tags](https://craftcms.com/docs/3.x/reference-tags.html) when it needs to store links to assets, entries, etc. in the database. This neatly sidesteps around the problem of having to do a find/replace every time you move environments since those URLs are "built up" on-the-fly.

However, this only works for new content the you create in the CMS. On the off-chance that you're moving legacy content from another CMS to Craft, you can use Craft's built-in find/replace tool inside Utilities to do the find/replace.

> Is there no other way to have a single large migration (contents, settings, fields, etc.) happening at once?

Generally you want your migration to go one-way.

You'll want to read up on [Project Config](https://craftcms.com/docs/3.x/project-config.html) but in general, you start on local then push your project config to staging or production. This prompts Craft to update the structural items in the CMS (added sections, fields, etc.)

Moving actual content from staging to production itself is more of a challenge. The Migration Assistant you linked up does lets you export content as well as structure, but usually you want to keep those sorts of changes as narrowly defined as possible.

Databases are highly structured beasts. When you start adding content on production then try to push an update from staging, that's a recipe for all sorts of breakage.

As an example, say you have an entry on staging that relates to a bunch of different categories, assets, and entries. Unless those entries, categories, and assets are already created on production, how does Craft know what to do with all of it?

On a technical level, primary and foreign keys could be different, for example. Some systems get around this with GUIDs, but in general, it's still a hard problem to solve unless the two are kept in sync somehow—which is what enterprise systems generally do.

WP for example has more tools to deal with this sort of thing but they're still more simplistic in this sense because it doesn't have all the relational capabilities of Craft.

> **Comments:**
> **username_0**: Hi RitterKnight. Thanks a lot for your thorough answer. Yes, you are right, I'm coming from WP(!), so in mind, there's always the step of exporting, and replacing data, the dB tables. It's great to hear that Craft completely avoids this problem.  I'll have to study the documentation well and do several tests to get an efficient and safe deployment method.  
> **username_0**: In the end, the plan is to get content from the Staging dB into our local machines; Media -images, videos, etc.- will remain in the Staging server; And we will commit and push to the remotes templates and other important files we change during dev.   Thank you for all the help and we will be probably knocking at the door soon with more questions.  

---

