Moving between PoE 1 and PoE 2: review assumptions, not just filenames

Two games can share a recognizable filter language without sharing every valid condition, item class, or useful assumption. That makes copying a familiar file from Path of Exile 1 into Path of Exile 2 deceptively attractive. Some lines may look perfectly ordinary while describing a property that belongs to a different game. The safest migration is therefore a review of intent and capabilities, not a search-and-replace exercise. This article outlines a way to preserve useful design choices while rebuilding the parts that require game-specific evidence.

Separate the language from the item model

A filter language defines instructions and their relationships: blocks, conditions, actions, operators, and control flow. The item model defines which properties exist and which values describe actual items. A file can be structurally understandable while still referring to the wrong game’s classes or properties. Likewise, an item name that appears plausible is not evidence that the selected client recognizes it. Treat syntax and item data as separate review tasks so that a pass on one does not obscure a failure on the other.

Start by marking every condition in the existing file. Ask what fact about an item it is trying to test. Then confirm that the destination game exposes a corresponding fact in its documented filter capabilities. The official documentation identifies game-specific conditions, including PoE 2 examples such as WaystoneTier and UnidentifiedItemTier. Their existence does not imply that they can be used interchangeably with similarly motivated conditions from another game. Keep the semantic question visible throughout the migration.

Preserve intent before preserving code

Write a plain-language purpose for each major block: highlight an upgrade family, show a resource, quiet ordinary equipment, or hide a deliberately excluded category. These purposes are often more portable than the conditions that implement them. A rule about the exact base needed by one character may have no useful destination equivalent. Rather than inventing one to preserve the block count, remove the obsolete goal or replace it with a new, explicitly justified goal.

Styles can sometimes transfer more easily. A high-priority palette, a restrained ordinary label, and a consistent sound vocabulary may remain useful even when the matching conditions change completely. Keep those style decisions in a separate note. The palette tool lets you inspect the visual system independently of item matching. Reusing a readable palette is different from claiming that the underlying rules are compatible, and your change notes should preserve that distinction.

Select the game before validating

A validator needs a capability context. If it evaluates a PoE 2 file against PoE 1 assumptions, it may reject legitimate instructions or miss inappropriate ones. Select the intended game and, where relevant, consider mode restrictions before reading the report. The documented distinction between Show, Hide, and Minimal is not merely stylistic: supported behavior depends on the target context. Do not solve a warning by changing the game selector until the result looks cleaner.

The Filter Validator checks its implemented subset and reports uncertainty or unsupported constructs. Review those messages instead of treating a zero-error count as certification. Documentation changes over time, and this article records a documentation review rather than a tested current client patch. If a new instruction is documented but not implemented by a browser tool, the appropriate next step is a focused manual review and client test, not an unsupported compatibility claim.

Rebuild your item examples for the destination game

Copied item text is evidence about a particular game’s representation of that item. Reusing old fixtures can conceal missing properties or lead to misleading defaults. Gather fresh representative item text from the destination game when possible, removing anything private before sharing it. Include ordinary examples, priority examples, and cases that should be hidden. Keep the original raw text alongside your expected outcome so that a parsing difference can be distinguished from a rule-order difference.

For every numeric condition, test boundary values. For every string condition, test a close non-match as well as an exact intended match. Equality, substring matching, and exact string matching should not be assumed equivalent. The Item Tester should report unknown where required properties or semantics are unavailable. That unknown result tells you which case needs another source of evidence. It is not a reason to silently fill an absent property with zero or an empty string.

Do not carry economy assumptions across games

A memorable highlight may have represented an item that was useful in a past character, league, or economy. That history does not establish its current importance elsewhere. This site does not supply live price feeds, economy-based tier refreshes, or account-aware recommendations. Its original starter data is a starting point for learning and customization. Treat any migrated priority as a personal decision that needs a reason, rather than as a market fact inherited from the old file.

Review strictness from a conservative baseline while you learn the destination game’s item needs. A broad hiding policy can remove the examples that would otherwise teach you what drops and what you care about. The Strictness Explorer helps frame the attention tradeoff, but it cannot identify a universally correct level. A file that was comfortable for a mature character may be unsuitable for a new character even within the same game.

Audit imports and external dependencies

A filter may depend on additional local files, optional imports, or custom sounds. Moving the main file alone does not necessarily move those dependencies. Create an inventory that names each referenced file and explains whether it is required for the intended behavior. The browser cannot resolve arbitrary local paths merely because a filter mentions them. If you have not explicitly supplied the dependency, its contents remain unverified from the tool’s point of view.

Check dependencies in the destination environment rather than assuming identical folders or available sounds. Do not copy assets unless you have the right to use them. Original filter text and licensed local assets are safer to maintain than an undocumented bundle acquired from unrelated sources. If an import contains game-specific rules, review it with the same care as the top-level file. A clean top-level report says little about instructions that were never available for inspection.

Keep installation evidence platform-specific

The fact that a filter loads on one desktop installation does not establish that the same local-file workflow exists on every platform. User document locations may differ, and client interfaces can change. Use the actual client’s folder-opening or selection controls where available. Follow the PoE 1 guide or PoE 2 guide according to the selected game, paying attention to verification notes instead of assuming the guides certify all systems.

Save the migrated file under a distinct name and preserve the original. Confirm both that the client lists the candidate and that it loads without an error. Then check representative item behavior. These are three different observations; recording only ‘installed successfully’ loses useful detail. A file can be visible in a selector but fail parsing, or load correctly while showing an unexpected item because a broad earlier block wins.

Compare the result against your original intentions

Use the Filter Compare tool to review what changed, but expect a deliberate migration to contain substantial differences. The goal is not the smallest possible diff. It is a file whose rules have clear reasons and fit the destination game. Review removals especially carefully: some represent obsolete concepts, while others may reveal an accidentally lost priority. Review additions for unsupported assumptions disguised as familiar-looking keywords.

Finish with a migration note that states the source purpose, target game, checked documentation, unresolved features, and in-game tests actually performed. Keep unverified cases explicit. Future you will benefit more from an honest limitation than from an optimistic compatibility badge. Moving between games becomes easier when the file’s intent, syntax, data, dependencies, and installation evidence are recorded separately. That structure also makes later updates more manageable, because you can identify which layer changed instead of starting over blindly.