Compare the Legacy SIR folder tree with the modern `users`, `modules`, and `commands` layout before migrating.

Why layout matters

The biggest source of migration mistakes is assuming that Legacy and Modern SIR store the same data in the same places. They do not.

Legacy centers everything around plugins/SIR/resources/.... Modern SIR spreads the runtime across:

users/
modules/
commands/
back-ups/

That split is cleaner, but it means direct copy-paste upgrades are risky.

Legacy vs Modern tree

Legacy

plugins/SIR/
  config.yml
  bossbars.yml
  webhooks.yml
  resources/
    modules/
      modules.yml
      advancements/
      announcements/
      chat/
      hook/
      join_quit/
      motd/
    commands/
      commands.yml
      announcer.yml
      clear-chat.yml
      msg-reply.yml
      print.yml
      sir.yml
      chat_color/
      chat_view/
      ignore/
      mute/

Modern

plugins/SIR/
  config.yml
  bossbars.yml
  webhooks.yml
  users/
    ignore.yml
    mute.yml
    chat-view.yml
    chat-color.yml
    nick.yml
  modules/
    states.yml
    announcements/
    join-quit/
    advancements/
    motd/
    channels/
    tags/
    moderation/
    emojis/
    cooldowns/
    mentions/
    discord/
    login/
    vanish/
  commands/
    lang.yml
    main/lang.yml
    states.yml
    clear-chat/
    color/
    ignore/
    message/
    mute/
    nick/
    print/
    settings/
  back-ups/

Shared files that survive the transition

Three root files remain conceptually stable across generations:

File	Legacy	Modern
`config.yml`	Global defaults	Still global defaults
`bossbars.yml`	Shared bossbar config	Still shared bossbar config
`webhooks.yml`	Shared webhook targets	Still shared webhook targets

These are the easiest pieces to recognize during migration, but they are not the full story.

What got split apart in Modern SIR

Old `chat/` folder

Legacy grouped these concerns together:

channel routing
cooldown rules
emoji replacement
mention detection
moderation checks
tag formatting

Modern SIR splits those into separate modules:

channels
cooldowns
emojis
mentions
moderation
tags

Old `hook/` folder

Legacy stored multiple integrations in one place:

discord.yml
login.yml
vanish.yml

Modern SIR separates them into:

modules/discord/
modules/login/
modules/vanish/

That is why copying hook/ straight into a newer server is not correct.

State files you should know

Modern file	What it stores
`modules/states.yml`	Enabled or disabled state for every module
`commands/states.yml`	Enabled or disabled state for every provider plus per-command override state
`users/ignore.yml`	Ignore relationships
`users/mute.yml`	Mute state and mute metadata
`users/chat-view.yml`	Per-player channel visibility
`users/chat-color.yml`	Per-player color selections

Legacy stored equivalent concepts in a more scattered way:

resources/modules/modules.yml
resources/commands/commands.yml
provider-specific data.yml files

Do not copy these blindly

The following areas should be reviewed instead of copied directly:

resources/modules/chat/*
resources/modules/hook/*
resources/commands/commands.yml
any permission plugin grants tied to Legacy node names
any custom automation that expects resources/commands/chat_color or resources/commands/chat_view

The migration service knows how to translate many of these pieces. A manual folder overwrite does not.

Optional jar-based loading in Modern SIR

Modern SIR is not only a static bundle. Its managers can also inspect bundled or external jars for:

additional modules
additional command providers

That is why the modules/ and commands/ folders are not just config folders. They are also part of the loader model and state persistence model.

This is still different from SIR+, which adds a dedicated addons/ runtime on top.

Safe comparison checklist before migrating

List every Legacy folder you actually customized.
Identify whether that folder maps to one modern module or many.
Review renamed permission nodes.
Compare resources/modules/modules.yml against the future modules/states.yml.
Compare resources/commands/commands.yml against the future commands/states.yml.
Validate player data files under users/ after the migration runs.

When you are ready for the actual move, continue with Migration Guide.

Configuration Layout