Change name of Laravel's created_at and updated_at
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Changing Names: Mapping Legacy Timestamps to Laravel's `created_at` and `updated_at`
Migrating a legacy application, especially one built on systems like WordPress, to a modern framework like Laravel often involves wrestling with database schema mismatches. One of the most common hurdles is dealing with timestamp columns. Laravel’s Eloquent ORM relies heavily on the convention that models use `created_at` and `updated_at` for tracking record history. When you encounter legacy names like `post_date` or `post_modified`, how do you bridge this gap without touching the live database structure?
This post dives into how to manage this scenario, focusing on practical, safe solutions for data migration and model mapping.
## The Challenge: Eloquent's Convention vs. Legacy Data
By default, Laravel expects two columns: `created_at` (set upon creation) and `updated_at` (set upon modification). If your underlying database uses different names—for example, `post_date` for creation and `post_modified` for updates—Eloquent will throw errors or fail to populate these critical fields unless explicitly told otherwise.
The core question is: Can we map `created_at` to `post_date` and `updated_at` to `post_modified` within the Eloquent framework? The short answer is no, not directly through simple naming conventions. Eloquent's internal mechanisms are tightly coupled to those specific column names.
## Solution 1: The Safe Approach – Database Migration (The Right Way for Schema Changes)
If you have control over the database schema and are performing a full migration, the safest approach is to rename the columns in the database itself during the migration process. This ensures data integrity and adheres to standard Laravel conventions from the start.
You would use a standard Laravel migration file to alter the table structure:
```php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Support\Facades\Schema;
class RenameTimestampColumns extends Migration
{
public function up()
{
Schema::table('posts', function (Blueprint $table) {
// Rename existing columns to Laravel standard names
$table->renameColumn('post_date', 'created_at');
$table->renameColumn('post_modified', 'updated_at');
});
}
public function down()
{
Schema::table('posts', function (Blueprint $table) {
// Revert the changes if rolling back
$table->renameColumn('created_at', 'post_date');
$table->renameColumn('updated_at', 'post_modified');
});
}
}
```
This method is robust, ensures future Laravel operations work perfectly (aligning with best practices found on the [Laravel documentation](https://laravelcompany.com/docs)), and requires no complex model logic.
## Solution 2: The Workaround – Custom Accessors for Legacy Reads
If you absolutely cannot modify the live database schema—perhaps due to strict constraints from the live WordPress environment—you must handle the mapping within your Eloquent Model layer. This involves creating custom accessors or mutators in your model to intercept the legacy column names when reading or writing data.
For instance, if you are only reading the data during a migration period and want Eloquent to *think* it’s seeing `created_at`, you can define this logic directly on the model.
```php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class Post extends Model
{
// Define the actual database column names used in the legacy system
protected $dates = [
'post_date', // The column name from the old DB
'post_modified',
];
/**
* Custom accessor to map legacy dates to Eloquent format.
*/
public function getCreatedAtAttribute($value)
{
// Map post_date (creation date) to created_