---
# 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.
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)Classic editor (CKEditor 5) no longer encapsulates the editing area in an `
See also [How to set the height of CKEditor 5 (Classic editor)](https://stackoverflow.com/questions/46559354/how-to-set-the-height-of-ckeditor-5-classic-editor).
| | [`autoUpdateElement`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-autoUpdateElement) | Defaults to `true`, cannot be disabled. | | [`baseFloatZIndex`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-baseFloatZIndex) | N/A. There is a dedicated [issue about `z-index` management](https://github.com/ckeditor/ckeditor5-ui/issues/218) and making it more open for developers. | | [`baseHref`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-baseHref) | Not supported yet, see https://github.com/ckeditor/ckeditor5/issues/665. | | [`basicEntities`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-basicEntities) | N/A | | [`blockedKeystrokes`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-blockedKeystrokes) | N/A | | [`bodyClass`](/ckeditor4/docs/#!/api/CKEDITOR.config-cfg-bodyClass) | Classic editor (CKEditor 5) no longer encapsulates the editing area in an `