* Add a `private static $table_name = 'MyDataObject'` for any custom DataObjects in your code that are namespaced. This ensures that your database table name will be `MyDataObject` instead of `Me_MyPackage_Model_MyDataObject` (converts your namespace to the table_name).
* Ensure you add [namespaces](http://php.net/manual/en/language.namespaces.php) to any custom classes in your `mysite` folder. Your namespaces should follow the pattern of `Vendor\Package` with anything additional defined at your discretion. **Note:** The `Page` and `PageController` classes *must* be defined in the global namespace (or without a namespace).
* Install the updated framework, CMS and any other modules you require by updating your `composer.json` configuration and running `composer update`. Some features have been split into their own modules, such as `asset-admin` and `errorpage`. Please refer to [`recipe-cms` composer.json](https://github.com/silverstripe/recipe-cms) and [`recipe-core` composer.json](https://github.com/silverstripe/recipe-core) for a list of recommended modules to include.
* Check if you need to adapt your code to changed PHP APIs. For more information please refer to [the changelog](/changelogs/4.0.0). There is an upgrader tool available to help you with most of the changes required (see below).
* Visit http://yoursite.com/dev/build/?flush=1 to rebuild the website database.
* Check if you have overwritten any core templates or styles which might need an update.
If you've already had a look over the changelog, you will see that there are some fundamental changes that need to be implemented to upgrade from 3.x. Here's a couple of the most important ones to consider:
* CMS CSS has been re-developed using Bootstrap 4 as a base.
* SilverStripe code _should_ now be [PSR-2 compliant](http://www.php-fig.org/psr/psr-2/). While this is not a requirement, we strongly suggest you switch over now. You can use tools such as [`phpcbf`](https://github.com/squizlabs/PHP_CodeSniffer/wiki/Fixing-Errors-Automatically) to do most of it automatically.
* We've also introduced some best practices for module development. [See the Modules article](/developer_guides/extending/modules) for more information.
## Additional tips easily missed
[Object class replaced by traits](/changelogs/4.0.0#object-replace)
The `Object` class has been superceded by three traits:
-`Injectable`: Provides `MyClass::create()` and `MyClass::singleton()`
-`Configurable`: Provides `MyClass::config()`
-`Extensible`: Provides all methods related to extensions (E.g. add_extension()).
`$this->class` no longer recommended, should use `static::class` or `get_class($classObject)` instead.
Use `$table = SilverStripe\ORM\DataObject::getSchema()->tableForField($model, $field)` instead of `$model` directly.
[Rewrite literal class names](/changelogs/4.0.0#literal-class-names)
For example, referencing the class name `'Member'` should be `Member::class` or if you're in YML config it should be `SilverStripe\Security\Member`.
[Template locations and references](/changelogs/4.0.0#template-locations)
Templates require the folder path inside the templates folder, and Core templates are placed in paths following the class namespace, e.g. `FormField` is now `SilverStripe/Forms/FormField`.
When using the `<% include %>` syntax, you can leave out the `Includes` folder in the path.
[Config settings should be set to `private static`](/changelogs/4.0.0#private-static)
We no longer support `public static $config_item` on classes, it now needs to be `private static $config_item`.
[Module paths can't be hardcoded](/changelogs/4.0.0#module-paths)
Modules may not be placed in a deterministic folder (e.g. `/framework`),
you should use getters on the [Module](api:SilverStripe\Core\Manifest\Module) object instead.
Please see the changelogs for more details on ways that the getters on the `Module` object could be used.
[Adapt tooling to modules in vendor folder](#vendor-folder)
SilverStripe modules are now placed in the `vendor` folder like many other composer package.
Modules need to declare which files need to be exposed via the new [vendor-plugin](https://github.com/silverstripe/vendor-plugin), using symlinks to link to files from the publically accessible `resources` folder.
[SS_Log replaced with PSR-3 logging](/changelogs/4.0.0#psr3-logging)
SilverStripe 4 introduces [PSR-3](http://www.php-fig.org/psr/psr-3/) compatible logger interfaces. Services can access the logger using the LoggerInterface::class service.
Please see the changelogs for more details on how to implement logging.
* "Micro" releases (x.y.z) are explicitly backwards compatible, "minor" and "major" releases can deprecate features and change APIs (see our [release process](/contributing/release_process) for details)
* The more custom features you have, the harder it will be to upgrade. You will have to re-test all of those features, and adapt to API changes in core.
* Customizations of a well defined type - such as custom page types or custom blog widgets - are going to be easier to upgrade than customisations that modify deep system internals like rewriting SQL queries.
