--- # Scope: # * Introduction to the migration problem. # * Underline that migrating is a complex and important task. # * List and clarify the things that need attention when migrating. category: builds-guides order: 260 --- # Migration from CKEditor 4 When compared to its predecessor, CKEditor 5 should be considered **a totally new editor**. Every single aspect of it was redesigned — from installation, to integration, to features, to its data model, and finally to its API. Therefore, moving applications using a previous CKEditor version to version 5 cannot be simply called an "upgrade". It is something bigger, so the "migration" term fits better. There is no "drop in" solution for migrating. In this guide we hope to summarize the most important aspects you need to consider before you proceed with installing CKEditor 5. Before starting, be sure that migrating is your best choice. Refer to {@link builds/guides/overview#When-NOT-to-use-builds When NOT to use CKEditor 5 Builds?} for more information. ## Installation and integration The very first aspect that changed with CKEditor 5 is its installation procedure. It became much more modern with the introduction of modular patterns, UMD, npm, etc. Refer to {@link builds/guides/integration/installation Installation} for more details. The API for integrating CKEditor with your pages also changed. It is worth checking {@link builds/guides/integration/basic-api Basic API} for an introduction. ## Features When it comes to features, there are two aspects that need to be taken into consideration: * CKEditor 5 may still not have the same features available as CKEditor 4. * Existing features may behave differently. Therefore, it is worth spending some time analyzing required features. CKEditor 5 was designed with focus on creating quality content. There are thus good reasons for it to not support some old features. You should take this chance to rethink the features available in your application and perhaps switch the approach towards a more modern reasoning. Features like text alignment, font size, family and colors are under development and will be added in the nearest future. ## Image upload Image upload is handled differently with CKEditor 5, bringing a much better user experience. Solutions used with CKEditor 4 may not be compatible anymore and therefore a new approach is needed. CKEditor 5 Builds come with {@link features/image-upload#Easy-Image Easy Image} available out of the box. It is super simple to {@link features/image-upload#Easy-Image enable image upload with it}. ## Plugins The trickiest migration challenge to be faced may be related to custom plugins you have developed for CKEditor 4. Although their concept may stay the same, their implementation will certainly be different and will require rewriting them from scratch. The same may apply for third-party plugins which may not have been ported to CKEditor 5 yet. Check the {@link builds/guides/development/plugins#Creating-plugins Creating plugins guide} for more information on the development of plugins. ## Themes (skins) In CKEditor 5, the previous concept of "skins" was reviewed and is now called "themes". If you have custom skins for CKEditor 4, these skins need to be recreated for CKEditor 5. Fortunately, {@link framework/guides/theme-customization custom theming} in CKEditor 5 is much more powerful and simpler than before. ## Existing data An extremely important aspect to be remembered is that — because of the difference in features — the **data produced with CKEditor 4 may not be compatible with CKEditor 5**. Extensive analysis, data verification and tests should be performed on existing data. If necessary, you will need to develop conversion procedures to avoid data loss. A relatively simple yet efficient strategy of adopting CKEditor 5 into existing systems might be using CKEditor 5 for creating new content and the old editor for editing legacy content. ## Configuration options compatibility table The following table presents configuration options available in CKEditor 4 and their equivalent in CKEditor 5. Note: The number of options was reduced on purpose. We understood that configuring CKEditor 4 was a bit too troublesome due to the number of configuration options available (over 240). Sometimes they were definitely too low-level, also many times they were so infrequently used that it did not justify the increased level of the application complexity. This is why when designing CKEditor 5 from scratch, we decided to come with a simplified editor, with well-thought default behavior, based on the results of the [Editor Recommendations](http://ckeditor.github.io/editor-recommendations/) project. | CKEditor 4 | CKEditor 5 | |----------|-------------| | [`allowedContent`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-allowedContent) |

Extending the list of HTML tags or attributes that CKEditor should support can be achieved by writing a plugin that (ideally) provides also means to control (insert, edit, delete) such markup.

For more information on how to create plugins check the {@link framework/guides/quick-start#Creating-a-simple-plugin Creating a simple plugin} article. Looking at the source code of CKEditor 5 plugins may also give you a lot of inspiration.

| | [`autoEmbed_widget`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-autoEmbed_widget) | Media embedding is not supported yet, but is planned. | | [`autoGrow_bottomSpace`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-autoGrow_bottomSpace)
[`autoGrow_maxHeight`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-autoGrow_maxHeight)
[`autoGrow_minHeight`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-autoGrow_minHeight)
[`autoGrow_onStartup`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-autoGrow_onStartup) |

Classic editor (CKEditor 5) no longer encapsulates the editing area in an `