Answers.Body: <p>Even after deleting the file, the migration will still show up in the UI because the migration history is stored in the database. You can use the console <a href="https://craftcms.com/docs/4.x/console-commands.html#migrate-mark" rel="nofollow noreferrer">command <code>migrate/mark</code></a> to set the migration history to a specific migration. First, reset the migration history:</p>
  <pre><code>php craft migrate/mark m000000_000000_base
  </code></pre>
  <p>This will remove the migration history and mark all migrations that still exist in the file system as pending. Now you can reset the migration history to the latest migration that you <em>do</em> want to keep and have already executed:</p>
  <pre><code>php craft migrate/mark m220727_164614_add_contact_form_group
  </code></pre>
  <p>This will mark the migration as having been executed so it won't show up as pending anymore.</p>
  <hr />
  <p>As a sidenote, for any changes to fields, sections, global sets and everything else related to the Craft configuration, I would heavily recommend using the <a href="https://craftcms.com/docs/4.x/project-config.html" rel="nofollow noreferrer">project-config</a> instead of migrations.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-28T11:08:50.057Z
Answers.Text: Amazing! Thanks as always for your input! Right, yes I was keying up between those two options (migrations, project config), but that makes it a bit easier to make the switch!
Answers.UserDisplayName: Wally
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-28T11:23:54.980Z
Answers.Text: @Wally If you're still on the fence, project config is _amazing_, it will save you so much time compared to writing everything manually in migrations. We use project config for everything and only use migrations for actual content migrations (i.e. populating an installation with default content, moving content between fields etc). Saves so much time compared to other systems and works really well with version control, especially if you're working in a distributed team using git and a pull request workflow.
Answers.UserDisplayName: MoritzLost
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-28T11:00:19.677Z
Answers.LastActivityDate: 2022-07-28T11:00:19.677Z
Answers.UserDisplayName: MoritzLost
Body: <p>I've started to play around with <strong>content migrations</strong> and have been following the Craft Quest course on the subject.</p>
  <p><em>I'm not sure if this is a situation you should ever find yourself in, in an ideal work flow, but just encase its worth asking.</em></p>
  <p>I created some generic content migration files <strong>which were flawed</strong>. I could spin them up using <code>migrate/up</code> but was unable to remove them with <code>migrate/down</code> - I then realised it was because of an error with the <strong>previous migration content file</strong>.</p>
  <p>So I was left with no way to remove these fields, so I deleted them in Craft (I know not very elegant) and decided to start fresh. <strong>I also deleted the files from the migrations folder</strong> <em>(this might have been a mistake - and not recommended as a workflow)</em>.</p>
  <p>But these files are still referenced in <code>Utilities &gt; Content Migration</code></p>
  <p><a href="https://i.sstatic.net/Azbox.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Azbox.png" alt="enter image description here" /></a></p>
  <p>So... Is there another way to remove these files from Craft?
  This is just dummy data but I'm interested as if it was real data then this could be an issue.</p>
  <p>Would you delete these inputs from the Database directly? If so how?</p>
  <p>Or, would you take the file names and re create them again in the migrations folder and write the correct spin/down function and run that? Or is there a command that can be issued in the migrate/down command that tells craft to invalidate this file.</p>
  <p>Or, is there a way to get Craft to clear its cached to see these file no longer exist?</p>
  <p>I did find this answer helpful, but in this use case it would boil down to <a href="https://craftcms.stackexchange.com/questions/36835/understanding-migrations-and-cli-commands">revert to a prior DB import</a>.</p>
  <p>Thanks for any help offered here, I know it's a hypothetical but has a real use case for future debugging.</p>
  
Tags: <migration>
Title: Remove deleted migration content without migrate/down
ThreadText: # Remove deleted migration content without migrate/down
  
  (Asked by: username_0 on 2022-07-28)
  
  I've started to play around with **content migrations** and have been following the Craft Quest course on the subject.
  
  *I'm not sure if this is a situation you should ever find yourself in, in an ideal work flow, but just encase its worth asking.*
  
  I created some generic content migration files **which were flawed**. I could spin them up using `migrate/up` but was unable to remove them with `migrate/down` - I then realised it was because of an error with the **previous migration content file**.
  
  So I was left with no way to remove these fields, so I deleted them in Craft (I know not very elegant) and decided to start fresh. **I also deleted the files from the migrations folder** *(this might have been a mistake - and not recommended as a workflow)*.
  
  But these files are still referenced in `Utilities > Content Migration`
  
  [![enter image description here](https://i.sstatic.net/Azbox.png)](https://i.sstatic.net/Azbox.png)
  
  So... Is there another way to remove these files from Craft?
  This is just dummy data but I'm interested as if it was real data then this could be an issue.
  
  Would you delete these inputs from the Database directly? If so how?
  
  Or, would you take the file names and re create them again in the migrations folder and write the correct spin/down function and run that? Or is there a command that can be issued in the migrate/down command that tells craft to invalidate this file.
  
  Or, is there a way to get Craft to clear its cached to see these file no longer exist?
  
  I did find this answer helpful, but in this use case it would boil down to [revert to a prior DB import](https://craftcms.stackexchange.com/questions/36835/understanding-migrations-and-cli-commands).
  
  Thanks for any help offered here, I know it's a hypothetical but has a real use case for future debugging.
  
  **Tags:** migration
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-07-28. Score: 2 | Accepted answer
  
  Even after deleting the file, the migration will still show up in the UI because the migration history is stored in the database. You can use the console [command `migrate/mark`](https://craftcms.com/docs/4.x/console-commands.html#migrate-mark) to set the migration history to a specific migration. First, reset the migration history:
  
  ```
  php craft migrate/mark m000000_000000_base
  
  ```
  
  This will remove the migration history and mark all migrations that still exist in the file system as pending. Now you can reset the migration history to the latest migration that you *do* want to keep and have already executed:
  
  ```
  php craft migrate/mark m220727_164614_add_contact_form_group
  
  ```
  
  This will mark the migration as having been executed so it won't show up as pending anymore.
  
  ---
  
  As a sidenote, for any changes to fields, sections, global sets and everything else related to the Craft configuration, I would heavily recommend using the [project-config](https://craftcms.com/docs/4.x/project-config.html) instead of migrations.
  
  > **Comments:**
  > **username_0**: Amazing! Thanks as always for your input! Right, yes I was keying up between those two options (migrations, project config), but that makes it a bit easier to make the switch!  
  > **username_1**: @username_0 If you're still on the fence, project config is _amazing_, it will save you so much time compared to writing everything manually in migrations. We use project config for everything and only use migrations for actual content migrations (i.e. populating an installation with default content, moving content between fields etc). Saves so much time compared to other systems and works really well with version control, especially if you're working in a distributed team using git and a pull request workflow.  
  
  ---
  
  