Symfony’s official recommendation is to opt for regular releases whenever possible and to upgrade regularly from 8.0 → 8.1 → 8.2… rather than staying on an LTS release for a long time.

In practical terms:

• Choosing Symfony 7.4 LTS makes sense if:
  • You have a highly sensitive business application (banking, healthcare, manufacturing),
  • update cycles are time-consuming,
  • You prioritize maximum short-term stability, even if it means carrying out a major migration later on.
• Choosing Symfony 8.0 makes sense if:
  • You can schedule updates every 6 months,
  • If you want to stay up to date with the latest features of the framework,
  • You’d rather spread out the migration effort over time rather than go through it every two years.

At Etixio, we recommend:

7.4 LTS for mission-critical, highly constrained applications;
8.0 (then 8.1, 8.2…) as soon as the team and project context allow.

2. Prerequisites: Symfony 8.0 requires PHP 8.4

Symfony 8.0 has made a bold choice: it requires at least PHP 8.4.
Why is this important to you?

• Security: PHP 8.4 is one of the versions that are actively maintained and patched.
• Performance: Symfony’s core takes advantage of the latest language optimizations.
• Syntax & DX: improved handling of types, attributes, modern structures, etc.

Before we even talk about Symfony, the first question to ask is:

“Is our infrastructure ready for PHP 8.4 (servers, Docker, CI/CD, extensions, dependencies)?”

At Etixio, we usually start by:

• a PHP 8.4compatibility audit,
• and then the gradual migration of the environment,
• before diving into the Symfony application core.

3. FormFlow: Finally, Clean, Multi-Step Forms

This is one of the most noticeable changes from a developer’s perspective: “form flows” are coming as a native feature.

Until now, for a multi-step form (registration wizard, onboarding, product setup, etc.), you had to:

• manage the session manually,
• track the user’s progress,
• create some “Previous” and “Next” buttons,
• handle partial validation, intermediate statuses, etc.

With FormFlow, Symfony introduces a dedicated concept:

• we extend AbstractFlowType instead ofAbstractType,
• Steps are declared using addStep(),
• We add a “navigator” for automatic navigation.

Simplified example:
use Symfony\Component\Form\Flow\AbstractFlowType;
use Symfony\Component\Form\Flow\FormFlowBuilderInterface;

class UserSignUpFlowType extends AbstractFlowType
{

public function buildFormFlow(FormFlowBuilderInterface $builder, array $options): void

$builder->addStep(‘personal’, UserSignUpPersonalType::class);
$builder ->addStep(‘professional’, UserSignUpProfessionalType::class);

$builder ->add(‘navigator’, NavigatorFlowType::class);

}

In the controller, we work with a flow rather than a simple form:

• isFinished() to determine when the process is complete,
• getStepForm() to display only the current step.

Result:

• less “glue” code,
• a more declarative approach,
• complex forms (multi-step, conditional) that are much easier to maintain.

4. Configuration: The End of XML, the Rise of Typed PHP

Symfony continues its extensive modernization of the configuration:

• XML is officially deprecated in version 7.4 and removed in version 8.0.
• The “fluent PHP config” is also being phased out in favor of a simpler PHP format.

4.1. The New Format: PHP “Array Shapes”

Symfony introduces a PHP configuration format based on typed arrays (“array shapes”):

• The syntax looks like YAML,
• But we’re sticking with pure PHP, using:
  • autocomplete in the IDE,
  • static analysis (PHPStan/Psalm),
  • type validation.

A typical example:

// config/packages/security.php
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

use Symfony\Component\DependencyInjection\Loader\Configurator\App;

return App::config([

‘security’ => [

‘firewalls’ => [

‘main’ => [

‘pattern’ => ‘^/*’,
‘lazy’ => true,
‘anonymous’ => true,

],

],
‘access_control’ => [

[‘path’ => ‘^/admin’, ‘roles’ => ‘ROLE_ADMIN’],

],

],

]);

For teams:

• Dev & lead dev: a format aligned with modern tools, making it easier to review and refactor.
• Organization: The configuration becomes easier to navigate and more reliable over the long term.

YAML is, of course, still supported, and its autocompletion has also been improved using JSON schemas.

5. JSON, Mapping, and Data: Symfony is Stepping Up Its Game on the API Front

Symfony is stepping up its game for API-oriented and data-intensive applications .

Three components, introduced in version 7.3, are now stable and fully supported:

1. JsonPath
   • Allows you to query complex JSON structures using a dedicated syntax.
   • Very useful for handling responses from third-party APIs.
2. JsonStreamer
   
   • Encodes and decodes JSON very quickly and with minimal memory usage.
   • Perfect for high-volume data flows (exports, ETL, microservices).
3. ObjectMapper

• • Simplifies mapping between entities, DTOs, API payloads, etc.
  • It saves a tremendous amount of time on all the “plumbing” involved in data transformation, especially when working with collections.

5.1. Improved management of “business” dates

The new form options (input=”date_point“) and dedicated Doctrine types (DayPointType, TimePointType) finally make it possible to clearly separate:

• “absolute” dates (such as a birthday or a due date that does not depend on a time zone),
• specific moments in time.

For business applications (contracts, subscriptions, reservations), this is a real plus in terms of reliability: fewer surprises related to time zones.

6. Code Quality & Security: Symfony Is Getting Stricter (And That’s Good News)

Versions 7.4 and 8.0 also provide an opportunity to remove ambiguous APIs and reinforce best practices.

6.1. End of Request::get()

The $request->get(‘id’) method is deprecated in 8.0.

Why?
Because it combined the following elements into a single method:

• route parameters,
• query string,
• POST payload.

Result:

• less readable code,
• risk of collisions,
• a larger attack surface in the event of a failed validation.

From now on, we need to be explicit:

$request ->attributes ->get(‘id’); // route parameters
$request ->query ->get(‘page’); // ?page=…
$request->request->get(’email’); // POST data

Or better yet: use the mapping attributes (#[MapQueryParameter], #[MapRequestPayload], etc.) directly in the controllers.

6.2. Console Commands: Making Way for “Invokable” Commands

Invocable commands are becoming much more powerful:

• a single class,
• an __invoke() method,
• attributes such as #[Argument], #[Input], #[Ask], and #[Interact] to handle arguments and user interaction.

It’s more readable, more distinctive, and easier to test.

6.3. Default UUID v7 and video validation

Symfony promotes the useof UUID v7 (with a timestamp component), which is better suited for database indexing and sorting.

There is also a new ” Video ” constraint for validating video files (duration, format, dimensions, etc.) using FFmpeg.

7. Migration Plan: Where to Start?

If you’re currently using Symfony 5.x, 6.x, or 7.0–7.3, here’s a realistic plan for upgrading to 7.4 / 8.0:

1. Upgrade the Infrastructure
   • Migrate to PHP 8.4 (or at least prepare the environment for the migration)
   • Check extensions, Docker images, CI pipelines, etc.
2. First, upgrade to Symfony 7.4
   • This is the “patch” version, which includes all the features of 8.0 along with the deprecated features.
3. Tracking Depreciation
   

   by running the tests with:

   php bin/phpunit –display-deprecations

   • correct what comes from the project code,
   • Track depreciation issues related to bundles and dependencies.
4. Clear the configuration
   • gradually migrate from XML to YAML or PHP,
   • Adopt the new PHP formats where it makes sense.
5. Switch to Symfony 8.0
   • Once the depreciation issues have been corrected, the transition is much smoother,
   • However, plan for a QA /performance testing phase to validate the changes.
6. Establish a schedule for updates
   • Plan the 8.1, 8.2, 8.3, and 8.4 upgrades,
   • Include depreciation management in the project’s “normal” technical debt.

8. How Etixio Can Help You

At Etixio, our Symfony teams are already helping clients with this transition to Symfony 7.4 / 8.0:

• Symfony & PHP 8.4 Audit
  • status report: version, dependencies, configuration, performance, security,
  • Mapping of impairments and risks.
• Custom Migration Plan
  • choice between 7.4 LTS and 8.0 (or both versions),
  • A detailed roadmap tailored to your product and business requirements.
• Implementation
  • refactoring legacy code,
  • Migration of complex forms to FormFlow,
  • configuration modernization (PHP array shapes, end of XML),
  • API optimization (JsonStreamer, ObjectMapper, JsonPath).
• Team Support
  • pair programming with your developers,
  • knowledge transfer regarding new Symfony practices,
  • helps establish a regular (and less painful) update cycle.

In summary

• 7.4 and 8.0 have the same features: the difference lies in technical debt and support.
• 8.0 requires PHP 8.4 and makes full use of the language’s modern features.
• FormFlow, the new PHP configuration, JsonStreamer/ObjectMapper/JsonPath, and the new validation constraints represent a significant leap in quality for serious projects.

If you’d like to:

• Prepare for your Symfony 8 migration,
• ensure your technical decisions are sound,
• or have an existing Symfony application audited before a redesign,

We can discuss this and work together a concrete plan tailored to your situation.