My C# is rusty, hopefully I haven’t glossed over any language constraints.

I would implement UpScript and DownScript as interfaces that have the same members:

public interface IUpScript {
    public long Version { get; private set; }
    public string Name { get; private set; }
    public string Content { get; private set; }
}
// ...
public interface IDownScript {
    public long Version { get; private set; }
    public string Name { get; private set; }
    public string Content { get; private set; }
}

This approach attempts to provide the minimal code needed to create a distinction between up and down, nothing more. Thoughts:

• Classes implementing an interface will have the common properties you’ve defined as in your other approaches but don’t inherit implementation details like a constructor.
• Your implementing classes would be free to extend other classes if they needed.
• It looks as though you don’t need to support multiple implementations of up and down scripts but you’d have no trouble doing so.

I think your solution with the abstract base class is just fine. It’s common OO programming: you have an abstract type with two different implementations. You should not worry about about duplication of creating two classes. In a language like Scala that provides some syntactic facilities, you can define such cases in a more concise way, but for C# and Java I don’t think you can do much better. In Scala you can use case classes for example:

trait Script(long version, string name, content)
case class UpScript(long version, string name, content) extends Script
case class DownScript(long version, string name, content) extends Script

About instantiation, in your current case it’s just fine as you have only two subclasses at the moment. You can think of having factories and then when reading the up files, use UpFactory, say, and vice versa. This way the client code will not be bound to the actual implementation.

The solution with the abstract base class is the way to go.

To reduce duplication in the code that determines which scripts to process, you can introduce a factory class/method that creates either a UpScript or a DownScript instance based on a parameter (the same parameter that determines if the scripts with the “_up” or the “_down” suffix should be used).

If the execution order of the scripts depends on the direction, you can add a comparison method to Script (with implementations in UpScript and DownScript) to correctly order the Script instances.
Execution of the scripts then becomes as easy as iterating over an ordered collection without needing to know if you are upgrading or downgrading.

How do I reduce the duplication without losing the expressiveness of having different classes?

By considering the scenarios in which your program interacts with the scripts, as stated in your top-level description:

1. Get a list of scripts off the filesystem
2. Execute the appropriate migrations on the database

The first decision is which up or down scripts to apply during migration:

public interface IScriptSource
{
    IEnumerable<IScript> ReadUpScripts();

    IEnumerable<IScript> ReadDownScripts();
}

The second decision is to execute each script, which will move the database forward or backward in time:

public interface IScript
{
    void Execute();
}

This gives us a nice basis for addressing your primary concern:

The problem that I have here is a few parts of code that are dealing with both either UpScript or DownScript instances look almost identical.

With these top-level abstractions in place, we can shape implementations around shared details:

public abstract class Script : IScript
{
    protected Script(long version, string name, string content)
    {
        Version = version;
        Name = name;
        Content = content;
    }

    protected long Version { get; private set; }
    protected string Name { get; private set; }
    protected string Content { get; private set; }

    public virtual void Execute()
    {
        SomethingShared();

        MoveInDirection();

        SomethingElseShared();
    }

    protected abstract void MoveInDirection();
}

Then differentiate the specifics of each type:

public sealed class UpScript : Script
{
    public UpScript(long version, string name, string content)
        : base(version, name, content)
    {}

    protected override void MoveInDirection()
    {
        // Up-specific
    }
}

public sealed class DownScript : Script
{
    public DownScript(long version, string name, string content)
        : base(version, name, content)
    {}

    protected override void MoveInDirection()
    {
        // Down-specific
    }

    protected override SomethingElseShared()
    {
        base.SomethingElseShared();

        // Down-specific
    }
}

This will help consolidate the spread-out code by pairing it directly with the data.

It also gets the Liskov stamp of approval due to IScriptSource hiding the concrete types.