# Migrating to Laravel 5: New Directory Structure and .env

> A walkthrough of the key changes when moving from Laravel 4 to 5 — directory layout, .env configuration, and application bootstrapping.

- Published: 2015-02-01
- Category: Framework & Library
- Tags: Laravel
- Reading time: 3 min read
- Source: https://www.muhammetsafak.com.tr/en/blog/migrating-to-laravel-5-directory-structure-and-env/
- Language: en-US
- Author: Muhammet Şafak

---
Laravel 5 ships its stable release in the coming days, and my first reaction was: familiar, yet completely different. [I had built several projects with Laravel 4](/en/blog/getting-started-with-my-first-laravel-4-project/) — the directory structure, config files, `app/models`, `app/controllers` — all of it was baked into muscle memory. Opening a fresh Laravel 5 project, I had a distinct "wait, did everything move?" moment.

A bit of research made it clear that the changes weren't a random reshuffling. This was a deliberate, well-considered restructuring. In this post I'll walk through the most important changes and how I adapted to them.

## Key directory structure changes

In Laravel 4, application code lived under `app/` and looked like this:

```
app/
  controllers/
  models/
  views/
  filters.php
  routes.php
```

Laravel 5 changed this significantly. The `models/` and `controllers/` directories are gone. Instead, `app/` is left open for you to organize however you like, following PSR-4 autoloading conventions.

```
app/
  Http/
    Controllers/
    Middleware/
    Requests/
  Providers/
  User.php
```

It might look messy at first glance, but it's actually more flexible. You can keep your models under `app/Models/` or directly inside `app/` — the framework doesn't dictate a folder structure; that's your call.

`routes.php` is now at `app/Http/routes.php`. Everything HTTP-related is grouped under `Http/` — a sensible decision.

## .env file and configuration management

This is my favorite change in Laravel 5. Previously, files like `app/config/database.php` and `app/config/mail.php` contained server credentials directly. You'd create separate subdirectories for each environment (`app/config/local/`, `app/config/production/`).

Laravel 5 drops that approach entirely and embraces `.env`. A `.env` file sits at the project root and holds sensitive configuration as plain text.

```ini
APP_ENV=local
APP_DEBUG=true
APP_KEY=SomeRandomKey

DB_HOST=localhost
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret
```

This file is added to `.gitignore` and never committed to version control. Each developer maintains their own `.env`. On the production server, the same variables are set either as environment variables or in a server-side `.env`. Config files now read these values via calls like `env('DB_HOST', 'localhost')`.

With this setup, database passwords and API keys never end up in [git history](/en/blog/switching-to-git-leaving-ftp-behind/). In my opinion, this is exactly the right move.

## Middleware

In Laravel 4, before/after request logic was handled by something called "filters." In Laravel 5, that concept is renamed to **middleware** and lives in `app/Http/Middleware/`. The underlying idea is the same; only the name and location changed. This shift was made as groundwork for PSR-7 compatibility.

## Service providers and application bootstrapping

Laravel 4 had startup files under `app/start/` — things like `global.php` and `artisan.php`. Those are gone. Everything you need to bootstrap your application is now managed through **service providers**. You register your own providers in the `providers` array inside `config/app.php`.

It felt like overhead at first, but the more service providers I wrote, the more I appreciated how organized this approach is.

## Migrations and the command line

Not much changed here — `artisan migrate` still works. But artisan commands have been expanded. Commands like `php artisan make:controller`, `php artisan make:model`, and `php artisan make:middleware` generate files in the correct directory using the correct stub. A small convenience that compounds quickly over time.

## How long did the migration take?

Rather than porting an existing Laravel 4 project in-place, I chose to start a fresh Laravel 5 project and move the code over piece by piece. There's no automated migration path; the architectural changes require manual adaptation.

Starting fresh produced a cleaner result. The migration took a few days, but in the end I had a tidier codebase and had picked up solid habits like properly using `.env`.

Laravel 5 looks like a breaking change at first glance, but it's genuinely a step in the right direction. A few days of patience is all it takes.