Let's run through a quick summary so I can reference this post in the future.

Forms are just classes. The way classes communicate with each other is via methods and properties. Someone out there is saying, "But what about events?" and the answer is events are fancy methods. (Think about it.) If you want many forms to be able to share information, you have to make methods and properties that each form is able to see.

One of the things people stumble on is for other things to see a method or property, you have to use the Public keyword. If you use any other keyword, then you need to memorize the VB Language Reference to understand when that means Public. I'm not going to say "public methods" or "public properties" any more from here on out, because unless I say otherwise that's what I mean.

Modules
The quick and dirty way is to use a Module. Properties and methods in a Module are "visible" to everything in the project. You don't have to worry about changing any existing Forms when you use a Module, you only have to start using it.
Code:
Public Module SomeModule

    Public Property SomeNumber As Integer

End Module

Class Form1

    Sub Form1_Load(...) Handles ...
        SomeModule.SomeNumber += 1
        Dim childForm As New Form2()
        childForm.Show()
    End Sub

End Class

Class Form2

    Sub Form2Load(...) Handles ...
        SomeModule.SomeNumber += 1
        MessageBox.Show(SomeModule.SomeNumber.ToString())
    End Sub

End Class
Keep in mind there's only one "copy" of Module variables. So if I wanted Form1 and Form2 to have a different SomeNumber than Form3 and Form4, I couldn't. I'd have to make a different property. But nothing would stop Form1/Form2 from accidentally modifying the wrong variable. That tends to be why professionals frown at Modules: when you put every variable in a place where everything in the project can access it, it's easier to make bad mistakes.

Shared Classes
These are basically Modules. If you make a class with only Shared properties and methods, those can be accessed from anything else just like Modules. The only difference between this approach and Modules is so subtle it's not worth talking about.

Classes
Most professionals use some variation of "not-Shared, not-Module" classes. We call them "instances" since that's easier to type.

Very new developers are opposed to making instance classes. There is a common belief that it is much harder to use them than Modules. Experts do not tend to agree with this view.

The extra complexity of instances is someone has to create the instance, and each Form that wants to see its methods and properties needs to have a variable that will "reference" the instance. Here is how the Module example might be changed to use an instance class:
Code:
Public Class SomeClass

    Public Property SomeNumber As Integer

End Module

Class Form1

    ' The "New" keyword creates instances.
    Private _myState As New SomeClass()

    Sub Form1_Load(...) Handles ...
        _myState.SomeNumber += 1
        Dim childForm As New Form2(_myState)
        childForm.Show()
    End Sub

End Class

Class Form2

    Private _myState As SomeClass

    ' Sub New() is what the "New" keyword looks for.
    Public Sub New(ByVal sharedState As SomeClass)
        ' This line is auto-generated by Visual Studio, do not add anything before it.
        InitializeComponent()

        ' Add anything you want Sub New() to do after InitializeComponent(). I mean it.
        _myState = sharedState
    End Sub

    Sub Form2Load(...) Handles ...
        _myState.SomeNumber += 1
        MessageBox.Show(_myState.SomeNumber.ToString())
    End Sub

End Class
Obviously it got bigger. I didn't promise it was "just as complex" to use instances. Instead I argue it's "worth the complexity".

To make an instance, you have to use the "New" keyword. It will call one of the type's Sub New() methods. If you didn't write any of those, one is automatically generated. Since Form1 is the "main form" in this example, it uses New to create the SomeClass instance that the forms will share.

We need to make sure Form2 sees the same object as Form1. So Form1 needs a way to give the object to Form2. I chose to add a Sub New() to Form2 that asks for the object as a parameter. Forms are special and have some magic code you don't usually see. Part of that magic is every Sub New() is supposed to call the InitializeComponent() method. Usually if you make a Sub New() in a Form, Visual Studio auto-generates this for you. If it doesn't, you'll be reminded quickly because none of your controls will be created when you run the form!

So Form1 gives the SomeClass instance to Form2 when it uses New to create the Form2 instance. When Form2 displays, it should display a message box that says "2". This is because SomeClass.SomeNumber starts with the value 0. When Form1 displays, it changes SomeNumber to 1. When Form2 displays, it changes SomeNumber to 2 then displays it.

Why do we bother? Well, now there are as many copies of SomeNumber as we care to make. Form1 and Form2 don't NEED to share the object. This code would give Form2 a unique instance of SomeClass:
Code:
Dim childForm As New Form2(New SomeClass())
That's usually not what you want. So keep in mind, every time you say "New", you're getting a different copy. Don't use it unless you aren't trying to share information between two forms.

Some people don't like messing with Sub New() and instead use properties:
Code:
Public Class SomeClass

    Public Property SomeNumber As Integer

End Module

Class Form1

    Private _myState As New SomeClass()

    Sub Form1_Load(...) Handles ...
        _myState.SomeNumber += 1
        Dim childForm As New Form2()
        childForm.State = _myState
        childForm.Show()
    End Sub

End Class

Class Form2

    Public Property State As SomeClass

    Sub Form2Load(...) Handles ...
        State.SomeNumber += 1
        MessageBox.Show(State.SomeNumber.ToString())
    End Sub

End Class
There are reasons why you might choose this instead of Sub New(), and there are reasons you might choose Sub New() instead. I don't think understanding those distinctions is as important as understanding they are both how you share references between classes.